Re: Cross platform development

2017-03-18 Thread pelzflorian (Florian Pelz) 
On 03/18/2017 04:03 PM, Michael Torrie wrote:
> On 03/18/2017 07:37 AM, Dirk Gottschalk via gtk-app-devel-list wrote:
>> The only chance is, to grab the DLLs from MinGW via objdump ore some
>> similar, like recommended and pack them into the applications working
>> directory, because Windows searches DLLs in its System, System32
>> subfolders and in the working directory of the app. This is tested. I
>> only want to copy just the needed files, not the complete DLL set Mingw
>> has on my systems, these are real much.
> 
> If you could find the msys2 binary packages, you could just grab the
> ones you need and unzip them into your app's custom tree.  I'm not sure
> where to get them, though. msys2's web site is very sparse and only
> shows the installers and the git source repos.  If I can find them I'll
> post here.
> 

MSYS2 ships with the pacman package manager. After you have followed the
instructions on the website, launch the MSYS2 shell from the MSYS2
folder and then this command installs everything you need to run gedit
into a filesystem tree inside your msys2 folder.

$ pacman -Syu --needed base-devel git
  mingw-w64-x86_64-binutils mingw-w64-x86_64-gcc
  mingw-w64-x86_64-pkg-config mingw-w64-x86_64-gtk3
  mingw-w64-x86_64-gedit

gedit ships this filesystem tree from msys2 but removes some files
needed only for building. It is somewhat large but a third of gedit’s
size is due to shipping python.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cross platform development

2017-03-18 Thread pelzflorian (Florian Pelz) 
On 03/18/2017 11:25 AM, Lucas Levrel via gtk-app-devel-list wrote:
> Le 17 mars 2017, à 23:02, Dirk Gottschalk via gtk-app-devel-list a écrit :
> 
>> I'm developing a multi platform application with GTK+ for Windows and
>> Linux.
>>
>>
>> IIRC is GTK+ and it's dependencies not linkable statically, which i
>> would prefer.
> 
> Yes, they are! I use this http://mxe.cc/ for my GTK2 app, but it has
> GTK3 also and many, many more libs! http://mxe.cc/#packages
> 
> As you can guess, with a statically linked exe, no more headache with
> lib distribution, installers and so on...
> 

Note that if your application is not libre software (it should be,
please make it libre!), then static linking means you need to provide
your application’s source code or compiled object files upon user
request so it can be relinked with another version of the LGPL’d
libraries. You will also still need to provide the other resources like
GTK’s schemas etc. But I have no experience with mxe.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cross platform development

2017-03-18 Thread pelzflorian (Florian Pelz) 
On 03/18/2017 08:07 AM, pelzflorian (Florian Pelz) wrote:
> gedit deploys msys2 but removes a bunch of files it does not need. This
> way, the binary will end up in a bin/ directory though. Of course you
> can make a link or a bat script for launching it in the main directory.
> 
> https://git.gnome.org/browse/gedit/tree/win32
> 

Note that this may become easier with Guix in the future

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00525.html

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cross platform development

2017-03-18 Thread pelzflorian (Florian Pelz) 
On 03/18/2017 04:07 AM, Michael Torrie wrote:
> I think some programs stick their binary and libraries in a bin folder,
> and GTK can still find it's files.  It's more typical for windows apps
> to put the EXE in the toplevel folder though.
> 

gedit deploys msys2 but removes a bunch of files it does not need. This
way, the binary will end up in a bin/ directory though. Of course you
can make a link or a bat script for launching it in the main directory.

https://git.gnome.org/browse/gedit/tree/win32

By the way, if you don’t download the sources of LGPL-licensed libraries
e.g. with msys2’s pacman, you rely on them still being available
on-line, because any user has the right to get the sources from you, so
if you don’t have them and cannot get them you can’t distribute your app
anymore. For commonly used libraries the sources will remain available
at least on the Internet Archive anyway though.

Regards,
Florian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk+-3.10.4 bundle and gtk+3.6 or what bundle for application 1 -10

2016-11-22 Thread pelzflorian (Florian Pelz) 
On 11/22/2016 12:04 AM, songqing shan wrote:
> Hi,
> 
> 
> I would like to have anyone to help me.
> 
> 
> I use MinGW+msys and gtk+-3.10.4 bundle to compile examples on the 
> https://developer.gnome.org/gtk3/stable/gtk-getting-started.html.
>  The examples in Sections (Basics, Packing, and Building interfaces) are 
> fine. However, following the instruction, I compile application 1-10, but no 
> any application works. All errors are similar. I give application 1 error as 
> follows.
> 

You may want to try a more current GTK+ with MSYS2 because the
documentation is for a current GTK+ too.

See for example
https://pelzflorian.de/gui-prog-gtk-2016/handout-01-install-en.pdf
for instructions.

> In addition, I used MinGW+msys and gtk+-3.6 bundle to compile another example 
> from anther website and the example works fine. However, after my computer 
> was scammed, I reinstalled MinGW+msys and gtk+-3.10.4 bundle and compile the 
> same example. following warnings occur,
> 
> ../src/editor.c: In function 'parameterizer_app_class_init':
> ../src/editor.c:652:39: warning: assignment from incompatible pointer type 
> [-Wincompatible-pointer-types]
>   G_APPLICATION_CLASS(class)->activate = parameterizer_app_activate;
>^
> ../src/editor.c:653:35: warning: assignment from incompatible pointer type 
> [-Wincompatible-pointer-types]
>   G_APPLICATION_CLASS(class)->open = parameterizer_app_open;
>^
> code:

Is parameterizer_app_activate declared like this?
static void parameterizer_app_activate (GApplication *app)

Regards,
Florian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Getting focus

2016-08-25 Thread pelzflorian (Florian Pelz) 
I believe shell integration is the only clean way to do a
Wayland-compatible guake. Am I wrong?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Fwd: Re: accessor functions in gtk3

2016-06-30 Thread pelzflorian (Florian Pelz) 
This too.

 Forwarded Message 
Subject: Re: accessor functions in gtk3
Date: Thu, 30 Jun 2016 14:38:49 -0700
From: Herminio Hernandez Jr <herminio.hernande...@gmail.com>
To: pelzflorian (Florian Pelz) <pelzflor...@pelzflorian.de>

On 06/30, pelzflorian (Florian Pelz) wrote:
> On 06/30/2016 07:25 AM, Herminio Hernandez Jr wrote:
> > The error I got was that 'im_context' was no a member of the struct 
> > GtkEntry. I believe the accessor function that I should use is 
> > gtk_entry_im_context_filter_keypress (). However I am having a hard time 
> > trying to figure out how to implement it. I just want to know am I looking 
> > in the wring place? Any advice would be appreciated.
> > 
> 
> What about the deleted-text and inserted-text signals of the EntryBuffer
> instead of the IMContext’s commit signal? I don’t think you can access
> the input method directly. Actually, I don’t know why you could do so in
> GTK+ 2.
> 
I think that worked! Thanks now off to fix all errors I am getting due
to moving from webkitgtk-1.0 to webkit2gtk...

Regards,
Herminio
> Regards,
> Florian
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Fwd: Re: accessor functions in gtk3

2016-06-30 Thread pelzflorian (Florian Pelz) 
This apparently should have been sent to the list.


 Forwarded Message 
Subject: Re: accessor functions in gtk3
Date: Thu, 30 Jun 2016 22:30:10 +0200
From: Nicolas Soubeiran 
To: pelzflor...@pelzflorian.de

Hi,
If I don't know about the im context (I do not see any accessor, and I
suppose the "previous" code was an hack) I've noticed the comment :
>   // The following signals replace the old "signal::changed", since that
>   // does not allow for the selection to be changed in it's callback.

It is not true :  you can change the value of an entry in the "changed"
signal, yet you have to block the connected signal (see
https://developer.gnome.org/gobject/stable/gobject-Signals.html#g-signal-handler-block
and others functions) to prevent recursive call.
the code should look like :
void my_entry_cbk (GtkEntry* entry , void* user_data)
{
g_signal_handlers_block_by_func (entry, my_entry_cbk, user_data);
...
gtk_entry_set_text (entry, new_text);
...
g_signal_handlers_unblock_by_func (entry, my_entry_cbk, user_data);
}
​or you ​can get the handler id when connecting the signal.


It should be easier to maintain than the current list of signal

Regards

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: accessor functions in gtk3

2016-06-30 Thread pelzflorian (Florian Pelz) 
On 06/30/2016 07:25 AM, Herminio Hernandez Jr wrote:
> The error I got was that 'im_context' was no a member of the struct GtkEntry. 
> I believe the accessor function that I should use is 
> gtk_entry_im_context_filter_keypress (). However I am having a hard time 
> trying to figure out how to implement it. I just want to know am I looking in 
> the wring place? Any advice would be appreciated.
> 

What about the deleted-text and inserted-text signals of the EntryBuffer
instead of the IMContext’s commit signal? I don’t think you can access
the input method directly. Actually, I don’t know why you could do so in
GTK+ 2.

Regards,
Florian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: disabling mouse scroll on GtkComboBox and spin buttons

2016-05-22 Thread Florian Pelz 
On 05/22/2016 11:54 AM, jcup...@gmail.com wrote:
> x = gtk_combo_box_new_text();
> g_signal_connect(x, "scroll-event", G_CALLBACK(true_cb), NULL);
> ...

Ah yes, this is a much better way.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: disabling mouse scroll on GtkComboBox and spin buttons

2016-05-22 Thread Florian Pelz 
On 05/22/2016 08:36 AM, Lokesh Chakka wrote:
> Hello,
> 
> Is there a way to disable mouse scroll on GtkComboBox and GtkSpinButton
> widgets ?
> 
> an example will help much.
> 
> Thanks & Regards
>

Use a function like

static void
disable_scroll (GtkWidget *widget)
{
  GdkEventMask events;
  events = gtk_widget_get_events (widget);
  events &= ~0 ^ GDK_SCROLL_MASK;
  gtk_widget_set_events (widget, events);

  if (GTK_IS_CONTAINER (widget))
gtk_container_forall (GTK_CONTAINER (widget),
  (GtkCallback) disable_scroll,
  NULL);
}

and then after creating the GtkComboBox call

gtk_container_forall (GTK_CONTAINER (combo),
  (GtkCallback) disable_scroll,
  NULL);

It seems to work for me on a GtkComboBox called combo, but I'm not sure
if it will survive on future GTK+ versions.

Regards,
Florian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

2016-05-06 Thread Florian Pelz 
On 05/06/2016 07:01 PM, Lucas Levrel wrote:
> Le 5 mai 2016, Andrew Robinson a écrit :
>> 1) Because there are between 40 to 120Mb worth of libraries or their
>> dependencies I would have to post on my website.
> 
> It's not clear to me whether one has to distribute GTK if it's linked
> statically, because one doesn't distribute the libs themselves. But I'm
> no lawyer and didn't investigate the question (I don't distribute
> publicly my small app).
> 

I'm not a lawyer, but:

Part of the idea of the LGPL is, as I understand it, that the user can
relink with a modified version of the library. Imagine party A gives an
LGPL library only to party B who then distributes an app linking with
the library to C. If B refuses C's request for the library's source
code, C has no way to link to a modified version of the library.
Therefore I believe you have to distribute the source code of the
library version you used at least upon request.

In particular, when linking statically, you also have to provide
linkable object files or source code for _your_ application.

I.e. you have to be able to provide source code for all LGPL portions no
matter if you use MSYS2, MXE, Fedora packages or compile the
dependencies yourself. There's no way around it.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

2016-05-04 Thread Florian Pelz 
On 05/04/2016 03:59 PM, Andrew Robinson wrote:
> No, there are no Win32 binaries in MSYS2. Where are you getting your
> information?
> 

MSYS2 contains pacman. `pacman -Syu mingw-w64-x86_64-gtk3` downloads
GTK+ binaries for x86_64 and puts them in the C:\msys64\mingw64
directory (by default). This directory is what you want to ship with
your application later on. Try it.


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

2016-05-04 Thread Florian Pelz 
On 05/04/2016 02:22 AM, Andrew Robinson wrote:
> I have an idea! Why doesn't someone just compile all the binaries for Win32
> and Win64 and make them available on the Internet, that way none of us will
> have to go through all this stupid BS just to get some binaries? Just two
> packages, one for Win32 and one for Win64, using only just the command line
> options that
> https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/
> tell us to use.

All the binaries are available and maintained in MSYS2. No need to
duplicate work.

If you want a newer Glib, you can try modifying the PKGBUILD and see if
it still works [1]. The version already seems right though.

You can also just download gedit for Windows, remove gedit.exe and put
in your .exe. You won't need some of the libraries and it's not very
clean and maintainable, but it's a quick hack to get a working GTK+.

And yes, Windows support could be a little cleaner and better
documented. It's not that bad though, people are working on it, and I'm
sure they'd appreciate help.

However, it seems many just ignore the LGPL when it comes to source code
distribution? Of course when using an unmodified version of glibc/GTK+/…
you can just find the library version you used and fetch the source code
from the upstream website when needed, but that may mean more work in
the future.

[1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-glib2

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

2016-05-03 Thread Florian Pelz 
On 05/03/2016 08:34 PM, Dov Grobgeld wrote:
> The complete gtk run time is only about 20MB in size (at least for gtk2)
> which with todays hard disk sizes really is negligable, so I agree that
> there is no reason to try to create a common gtk runtime.
> 
> I still remember the frustration back in the days when there was a common
> run environment and installing glade would make inkscape or gimp fail, or
> vice verse. Individual run time environments is really the way to go!
> 
> For a peak into the bad old days, see e.g. the following thread:
> http://comments.gmane.org/gmane.comp.gnome.gtk%2B.general/16828
> 
> 
> Regards,
> Dov
> 

This is convincing. Thank you.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

2016-05-03 Thread Florian Pelz 
On 05/03/2016 06:12 PM, Dave Howorth wrote:
> On 2016-05-03 16:57, Florian Pelz wrote:
>> I'd like to have one standard GTK+ installer for the GTK+ DLLs etc. that
>> can be downloaded and installed from other installers, so there is just
>> one GTK+ installed on Windows instead of one copy of perhaps different
>> versions of GTK+ for each application.
> 
> That's been a longstanding desire of many people. The other side of the
> argument of course is that all the applications have to be compatible
> with that particular version of the libraries, which has sometimes
> proven to be problematic even when the libraries ship with Windows.
> Expecting every application to be updated every time there is a library
> update is not realistic. It's not like a linux distro where the distro
> can update and recompile all the dependencies itself.
>

That's a good argument, but those who don't want to risk breakage due to
incompatibilities could still bundle it the old-fashioned way. Of
course, maybe it's too much effort and most people prefer stability on
Windows. I'm not going to take the time, so thank you for explaining the
reasons.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

2016-05-03 Thread Florian Pelz 
On 05/03/2016 04:57 PM, Andrew Robinson wrote:
> Well I can't ship MSYS2 and MXE with my application, and I most certainly
> can't sell any application to grandma and grandpa, if it requires instructions
> on how to install MSYS2 and MXE just so you can run my application.
> 

For MSYS2, you create a package for installing your application in
MSYS2. Then you use a clean MSYS2 installation with which you install
your application package and all dependencies. You can then copy the
installed directories and contents and use them as a bundle. You still
have to ship the GTK+ source code you used though.

Look at gedit for an example:

https://git.gnome.org/browse/gedit/tree/win32/make-gedit-installer

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Compiling for Windows [Was: argv revisited]

2016-05-02 Thread Florian Pelz 
On 05/02/2016 12:36 PM, Lucas Levrel wrote:
> […]
> 
> I'm not an expert programmer and when I wanted to compile for Windows
> the software I developped in Linux, I couldn't achieve a satisfactory
> result (using the -mwin32 or -mwindows flag gave either a clumsy
> additional command window, or yielded an antivirus alert!).
> 
> Then I found MinGW Cross Env, now called MXE (http://mxe.cc/). It
> compiled my project with no effort at all. When you install it, it
> compiles the cross-compiler and the libs you want, so this takes quite
> long, but with no user intervention. Then all you have to do is add such
> lines in your Linux-ready Makefile:
> 
> # prepend all binaries with a later-defined prefix
> PKG_CONFIG=$(CROSS)pkg-config
> CXX=$(CROSS)g++
> LD=$(CROSS)ld
> AR=$(CROSS)ar
> STRIP=$(CROSS)strip
> ...
> # define the prefix in the rules targeting Windows
> myrule : CROSS=/path/to/bin/i686-pc-mingw32-
> myrule : ...
> 
> HTH
> 

This is interesting. May I hijack this thread?

I did not know about MXE. What is their relationship with MSYS2?

Distributing the GTK+ source code with bundles for LGPL compliance seems
easier with MXE. How do others handle source code distribution? This is
not an issue for GNOME projects and I can't find examples.

Is it really necessary for every Windows application bundle to ship its
own copy of GTK+?

Regards,
Florian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Suggestion for text editing module

2016-04-18 Thread Florian Pelz 
On 04/18/2016 04:43 PM, Matthew A. Postiff wrote:
> Thank you for this suggestion. It might work. We are not doing WYSIWIG
> because our focus is on the text. Someday it would be nice to add a
> third view like print layout but for now we just have (1) text view and
> (2) usfm-with-formatting-codes-view.
> 

I was thinking it might not be suitable for the pretty view. That said,
I don't know much about GtkSourceView.


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Suggestion for text editing module

2016-04-18 Thread Florian Pelz 
On 04/17/2016 02:04 PM, Matthew A. Postiff wrote:
> Hi,
> 
> I have a gtk2 app that is, among other things, an editor for a data
> format called USFM. The program can display the data (text) in the
> encoded format, or in a pretty format, and the user can edit the data in
> either view. The editor is hand-built and somewhat buggy. I was
> wondering if you all have any suggestions for a pre-existing text
> editor/source code editor module that I could drop into my app, with
> some customization, to replace the buggy code?
> 
> […]

There is GtkSourceView, but it is probably not suitable for varying font
sizes, i.e. WYSIWIG formatting etc. I think it's also GTK+ 3 only. gedit
uses it.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-16 Thread Florian Pelz 
On 04/16/2016 07:59 PM, Andrew Robinson wrote:
> Don't forget that GTK is already running on top of the Windows command line
> and therefore I have no direct access to it. Everything is processed by GTK
> before I can ever get to it for myself.
> 
> I do suspect that Windows may be the cause of this issue, but I have no proof
> of it. One way to narrow down this issue was to see if anybody could reproduce
> this issue, but that isn't going to happen.
> 
> Don't worry about it though, I am abandoning this project as of today.
> 

I'm not sure if you are still on the list, so I'm cc'ing you.

I hope you reconsider what you think about our community. We are trying
to help.

While GTK+ could alter your command-line when the GTK+ DLL loads (like
this for example [1]) if it wanted to, it does not do so. That neither
Windows nor GoLink place argc and argv on the stack as you expect is a
far more likely explanation than an error in GTK+. Also, [2] makes it
sound likely. The workaround they describe is calling the Windows API
function GetCommandLine() to retrieve argc and argv. Doing so would
probably solve your problem and save your project.

By the way, you can bundle GTK+ programs like the Windows version of
gedit does [3]. It is plug and play and the bundle isn't that large.
However, it is not easy to create such a bundle.

[1] https://git.gnome.org/browse/glib/tree/glib/gconstructor.h
[2]
https://stackoverflow.com/questions/21946783/accessing-command-line-arguments-in-asm-win-7
[3] https://wiki.gnome.org/Apps/Gedit
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-16 Thread Florian Pelz 
On 04/16/2016 06:50 PM, Andrew Robinson wrote:
> Assembly language has no calling convention whatsoever until you hand code it
> to have whatever calling convention you want it to have, preferably matching
> the calling convention of whatever you are interfacing to.
> 

This is not a matter of calling convention.

If I understand you correctly, your problem is that argc and argv are
not stored where you expect them to be. My (and your?) theory is that
argc and argv are not being set up the way you expect them to be.

However, it is *not* GTK+ that sets up argc and argv before your entry
point gets called. It is either the operating system or some
linker-generated machine code you don't normally get to see. That is,
not everything in your .exe file is part of your assembly code. This is
why I suggested you check GoLink documentation, GoDev forums and the
answers on Stack Overflow about GoLink instead of GTK+.

> Have you actually ever programmed in assembly?
> 

Yes.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-16 Thread Florian Pelz 
On 04/16/2016 06:23 PM, Andrew Robinson wrote:
> That is completely incorrect. By definition, main(argc,argv) means that before
> you add even one line of code, argc and argv are on the stack, ready to be
> used. 

That's how it should be in C, but not necessarily in assemblers. Since
you seem to know assembly programming fairly well otherwise, I assume
the "bug" is that this is not the case here.

Maybe this helps you:
https://stackoverflow.com/questions/21946783/accessing-command-line-arguments-in-asm-win-7

Or maybe I still misunderstand you.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-16 Thread Florian Pelz 
On 04/16/2016 10:53 AM, Lucas Levrel wrote:
> Gtk2 came with "gtk-demo". Doesn't Gtk3 have a similar app? However, I
> don't know if it parses command-line args, if that's what you're looking
> for.
>

It is called gtk3-demo and it doesn't parse command-line args because
its examples are not run from the command-line. AFAIK gtk_init will
probably lose it's command-line parsing ability anyway and use only
environment variables instead. I'm not sure though. Of course
command-line parsing can still be useful for the application itself.

Probably it wouldn't help Andrew anyway because gtk3-demo is written in
C and the GoDev tools don't include a C compiler. What Andrew is asking
for is a GoAsm assembly language GTK+ example program if I'm not mistaken.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-16 Thread Florian Pelz 
GTK+ has no influence on the command line until you call gtk_init on it,
after which a valid command line remains a valid command line. Your
problem is not related to GTK+. What influences the command line is the
way GoLink calls main, so you should be asking your question on the
GoDev forum. Alternatively, you can use GCC instead of GoDev and follow
the advice given to you.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-15 Thread Florian Pelz 
On 04/15/2016 09:59 PM, Andrew Robinson wrote:
> I may be the only person writing a
> program in GoAsm for for GTK+3 and cross-OS, but that has nothing to do with
> my problem.

That you use GoAsm and GoLink instead of GCC can make a difference.
Different build toolchains may not be compatible. Where did you get your
GTK+ packages from? Does calling GTK+ functions even work?

Either way, the stack usage is probably the same for all 32-bit Windows
programs. In the MSYS2 GCC, argc is at ebp+8, argv is at ebp+12, so
argv[1] is retrieved like this:

moveax, DWORD PTR [ebp+12]
moveax, DWORD PTR [eax+4]

Maybe you accessed the argv array pointer instead of the array elements?

You can try it yourself on MSYS2 and compiling to assembler code like this

gcc `pkg-config --cflags gtk+-3.0` -S test.c -masm=intel

and linking like this:

gcc -o test test.s `pkg-config --libs gtk+-3.0`

I have no idea how to do this in GoAsm and I'm not going to try.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-15 Thread Florian Pelz 
On 04/15/2016 09:30 PM, Mark Cianfaglione wrote:
> […]
> To the community's defense I have to say that I've never seen anyone use
> ANY Gtk from assembler in the 7+ years that I've been using it. (Other
> than what is compiled from GCC.)
> 
> Sounds like you are breaking new ground. Do keep the list posted if you
> do manage to get it to work to add to the community based knowledge.
> 
> Mark
>

There is "Programming From the Ground Up" [1], an excellent but old book
on x86 (i.e. 32-bit) assembler programming on GNU/Linux which has a
section on using libgnomeui from the assembler. It uses the GNU
assembler's AT syntax by the way, not Intel syntax.

[1] https://savannah.nongnu.org/projects/pgubook/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv

2016-04-15 Thread Florian Pelz 
On 04/12/2016 01:58 PM, David Marceau wrote:
> If you really need to resort to assembler, just run the gcc/g++ compiler
> with the "-c -S" to generate the assembler to see how they gcc compiler
> does it with the above gtkhello.c

This here really is good advice. If you don't want to read GNU assembler
language, then make gcc output Intel assembler syntax (see [1]).

That said, you are asking for advice on a GTK+ list when your problems
apparently have nothing to do with GTK+.

[1]
https://stackoverflow.com/questions/199966/how-do-you-use-gcc-to-generate-assembly-code-in-intel-syntax

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list