Now that Ted has added the #ifdefs (yeah, I hate those, too) to prefsdialog.* the build is working again. Thanks, Ted!
The Gtk::Socket docs say that it is implemented with X's XEMBED protocol, which of course will work on neither W32 nor native OSX. Kak zhal! Maybe Mozilla's source tree has a cross-platform way of mounting one process's gui in that of another. Gnome's Corba v.3 way (activation like ActiveX) of doing it is cross-platform, but of course that would lead to infinite dependencies.
I couldn't reply to the mail thread here, since this work email account is not receiving all of the messages that my home account does.
Anyway, the cvs build for this morning is: http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0501130741....
Bob
On Thu, 2005-01-13 at 07:54 -0600, Bob Jamison wrote:
The Gtk::Socket docs say that it is implemented with X's XEMBED protocol, which of course will work on neither W32 nor native OSX. Kak zhal! Maybe Mozilla's source tree has a cross-platform way of mounting one process's gui in that of another. Gnome's Corba v.3 way (activation like ActiveX) of doing it is cross-platform, but of course that would lead to infinite dependencies.
Yeah, and that's what made me worried. But, I've been told, that there might be a way to do it on Windows too (obviously not using XEMBED). I'm curious if it is a documentation error in GTK+ or just a fact that Sockets/Plugs haven't been implemented on win32.
--Ted
On Thu, 13 Jan 2005, Ted Gould wrote:
Yeah, and that's what made me worried. But, I've been told, that there might be a way to do it on Windows too (obviously not using XEMBED).
It's doable in principle. Assuming my memory is correct, Windows in Win32 are a global resource, so it should just a matter of getting the HWND for the other process' "plug" window somehow (you have a lot of APIs to choose from) and then reparenting the window appropriately.
I'm curious if it is a documentation error in GTK+ or just a fact that Sockets/Plugs haven't been implemented on win32.
Would you like to volunteer? I believe it's been a TODO item for ages upon ages.
-mental
On Thu, 2005-01-13 at 13:49 -0500, MenTaLguY wrote:
I'm curious if it is a documentation error in GTK+ or just a fact that Sockets/Plugs haven't been implemented on win32.
Would you like to volunteer? I believe it's been a TODO item for ages upon ages.
Heh, I've doubled my knowledge of windows programming by reading your e-mail :)
So, I guess the real question is:
It doesn't appear that this is supported on windows. Do we want reduced functionality on Windows until it gets fixed? Or, do we want to scrap the idea of scripts having GUI preferences? (it could still be available for plug-ins, other languages, but nothing out of process)
--Ted
Ted Gould wrote:
So, I guess the real question is:
It doesn't appear that this is supported on windows. Do we want reduced functionality on Windows until it gets fixed? Or, do we want to scrap the idea of scripts having GUI preferences? (it could still be available for plug-ins, other languages, but nothing out of process)
EEEEEEEEEEEeeeeeeeeeeeeeeeeeeekkkkkkkkkkkk!!!!!!!!!!!!
That's the kind of embedding that's given me the willies for some time.
I'm more of the mind that instead of that approach, we should do a more "logical" approach (as opposed to "physical") and work more along the lines of XUL, Glade, XForms, etc.
On Fri, 14 Jan 2005, Ted Gould wrote:
So, I guess the real question is:
It doesn't appear that this is supported on windows. Do we want reduced functionality on Windows until it gets fixed?
It's unlikely to get fixed.
Or, do we want to scrap the idea of scripts having GUI preferences? (it could still be available for plug-ins, other languages, but nothing out of process)
Frankly, I'm with JonCruz on this one -- socket windows are the wrong way to go about this conceptually anyway, in general.
We want something more semantically rich. To begin with, something simple and more domain-specific might be appropriate, rather than trying to implement XBL+XUL or something (I'd kind of like to get our XML infrastructure cleaned up a LOT first...).
-mental
On Fri, 2005-01-14 at 18:51 -0500, MenTaLguY wrote:
Frankly, I'm with JonCruz on this one -- socket windows are the wrong way to go about this conceptually anyway, in general.
We want something more semantically rich. To begin with, something simple and more domain-specific might be appropriate, rather than trying to implement XBL+XUL or something (I'd kind of like to get our XML infrastructure cleaned up a LOT first...).
I guess there is two points here for me:
1) Then we can't do things like embed KDE's print dialog, or perhaps Window's. Those are minor cases, but I'm sure more will come along.
2) I really don't want to define our own format for GUI description... that seems like alot of effort for little gain. If we could piggyback on Glade that wouldn't seem that bad.
Perhaps if we had a list of functions you could connect to, then you could set the data to something like extension name and parameter name, and then it would set to the value. Would that work for people?
--Ted
On Sat, 15 Jan 2005, Ted Gould wrote:
On Fri, 2005-01-14 at 18:51 -0500, MenTaLguY wrote:
Frankly, I'm with JonCruz on this one -- socket windows are the wrong way to go about this conceptually anyway, in general.
We want something more semantically rich. To begin with, something simple and more domain-specific might be appropriate, rather than trying to implement XBL+XUL or something (I'd kind of like to get our XML infrastructure cleaned up a LOT first...).
I guess there is two points here for me:
- Then we can't do things like embed KDE's print dialog, or perhaps
Window's. Those are minor cases, but I'm sure more will come along.
- I really don't want to define our own format for GUI description...
that seems like alot of effort for little gain. If we could piggyback on Glade that wouldn't seem that bad.
There was some discussion about this today on Jabber (see logs). JonCruz has some ideas along the lines of either employing glade or XForms/XUL for this. Personally, I think this would take a considerable amount of coding to do, but Jon thinks it'd be straightforward given the appropriate DOM connections underneath. In any case, I think it would be valuable to experiment with making some proof of concepts for this outside the main codebase. It would be wise to do this separately from the codebase in case one runs into a blind alley, or if it causes some new dependencies - we'd like to make sure the idea is good before committing to adding a new dep that packagers or users might run into problems with.
Bryce
On Sat, 2005-01-15 at 13:26 -0800, Bryce Harrington wrote:
- I really don't want to define our own format for GUI description...
that seems like alot of effort for little gain. If we could piggyback on Glade that wouldn't seem that bad.
There was some discussion about this today on Jabber (see logs). JonCruz has some ideas along the lines of either employing glade or XForms/XUL for this. Personally, I think this would take a considerable amount of coding to do, but Jon thinks it'd be straightforward given the appropriate DOM connections underneath.
I read through the discussion, and I still can't see any reason to add a XUL dependency. I can't imagine that it wouldn't be huge, plus there is no GUI tool that I know of to create it. I think that one of our goals was to make creating scripts easy -- I think that Glade would make it easier for people creating scripts. Also, Glade is already tied into GTK+ (a current dependency) and it may already be part of the GtkMM integration. Lastly, I don't see any advantage with using the Inkscape XML representation with any way that we create because it will be independent of any type of repr access, everything should tie into extension parameters, which would be a set of functions.
So, I guess I see a plan as follows:
- I'll make the generic preference interface pass back a Gtk::Widget *
- Scripts won't work right now, the first person to implement it gets to choose how they do it :)
--Ted
Ted Gould wrote:
I read through the discussion, and I still can't see any reason to add a XUL dependency. I can't imagine that it wouldn't be huge, plus there is no GUI tool that I know of to create it.
I'm not pushing to add a XUL dependency per se, just that some approach along those lines could be good.
I think that one of our goals was to make creating scripts easy -- I think that Glade would make it easier for people creating scripts.
A little bit. But then again, Glade's markup is heavily presentational. Script authors could get suck into doing all sorts of 'detail' stuff and not get to focus on funtionality.
Also, Glade is already tied into GTK+ (a current dependency) and it may already be part of the GtkMM integration. Lastly, I don't see any advantage with using the Inkscape XML representation with any way that we create because it will be independent of any type of repr access, everything should tie into extension parameters, which would be a set of functions.
Tie in, yes. "set of functions" maybe or maybe not.
Then again, those doing scripts should be having to deal with DOM and tree structures anyway. So applying that same knowledge to the preference running would mean a consistent paradigm and interface for those doing scripting.
So, I guess I see a plan as follows:
- I'll make the generic preference interface pass back a Gtk::Widget *
EEEEEEEeeeeeeeeeeeeeeeeeeekkkkkk!!!!!!!!
- Scripts won't work right now, the first person to implement it gets to
choose how they do it :)
Sounds good.
participants (5)
-
Bob Jamison -
Bryce Harrington -
Jon A. Cruz -
MenTaLguY -
Ted Gould