2009/3/24 Marco Diego Aurélio Mesquita <[email protected]>: > Let's go slowly... >
Heh, I was surprised how quick you were starting out, figured I'd lay it on ;-) ... ok ... have you dealt with any stdin/stdout piped ipc programming before ? ... if not I can help you out with that its not big a deal (we dont have anything fancy like dbus at our disposal since were portable, but for our purposes some GIOChannels on stdin/stdout will do the trick). > 2009/3/24 Tristan Van Berkom <[email protected]>: >> [...] >> >> So now you have a glade_project_save & glade_project_save_full or >> something, so your going to want to export glade_project_preview >> (GladeProject *project, GladeWidget *widget), > > What? Why? Should I write a function called glade_project_preview? > What should I do with its parameters? glade_project_preview() will be the entry point to spawn the preview, we need an entry point in the core (glade3/gladeui/..) ... and then we will access the feature either from the plugin (glade3/plugins/gtk+/...) by way of action context menus... or we could also access it from the frontend (glade3/src/...) by way of the project or view menu (or alternatively in other frontends, like Anjuta). >> from here you'll want to add the io channel/spawn with pipes code, so from >> there you can pass the buffer to the "preview" app via its stdin. > > I would like to let the preview be a modal option. So that the user > could edit the interface, then preview it, then close the preview to > continue editing it. Hmmm, generally we dont like modal dialogs, I've gone to some lengths to make sure the widget editor dialogs dont have to be modal, there is also something tricky to that: writing portable code that will make a window from a foreign process "transient". The main reason why I want the preview to be in a separate process (btw) is because unfinished Glade files are untrusted; I'd much rather crash a child process and report a usable error about why GtkBuilder may have aborted than crash Glade in a preview routine. What if a preview could be updated ? (i.e. when the project changes then the preview is updated, until the preview window is closed and exits or is killed because a project was closed)... we can also add "raise-to-front" commands to the preview process and avoid spawning multiple previews for the same ancestry (may have some issues when toplevels get parented... can get to that later) Now, not all of this needs to be done at once ofcourse... > Some doubts remain: > Where and how should I send my patch? bugzilla.gnome.org, enter a bug for the glade3 product and Juan and I will receive bugmail about it and track the patches etc. > What to do with projects that do not have a toplevel widget? The preview can create a toplevel and child the widget, a prerequisite of glade_project_preview (GladeProject *project,GladeWidget * widget) is that (GTK_IS_WIDGET (widget->object) && widget->parent == NULL) (i.e. a preview is created for a GladeWidget which must be a toplevel project object, and it must wrap a GtkWidget). > What to do with projects that have many toplevel widgets? Another reason why we have the api that includes a widget specific parameter ;-) > (It doesn't even work if the project doesn't have a widget called "window1") ... And the GladeWidget parameter has a member widget->name, which will be the name of the widget to display in the project ... look at bleeding edge builder apis, if Im not mistaken your now allowed to build fragments of the UI instead of the whole file (like we had with libglade). Then I guess the best way to integrate the feature will be via an "important" action in the plugin, actions are implemented at a widget class level and available in the context menu in the workspace or inspector; "important" ones also show up in the main toolbar. The actions are outlined here actually: http://glade.gnome.org/docs/widgetclasses.html (actually, if you havent seen the docs, you should check em out/skim over them; I rewrote them last summer and they describe the core/plugin relationship pretty well) OK, so I said alot, what would we need I guess for a first revision of preview ? - a preview main built and installed from glade3/gladeui (glade-3-preview ?) - a basic expandable protocol outline for communication between the glade core and the preview (luckily now we have portable GChildWatchSources which will make this easier...), this protocol has to implement only 2 commands: - the initial preview command along with the transmission of the project glade file and the widget name to preview. - the kill command (which results in the preview exiting) - GladeProject to maintain a list of running previews and kill them at close time, update it when they exit on their own (using GChildWatchSource) - An action in the GTK+ plugin in the base GtkWidget adaptor definition to spawn the preview (i.e. one line in the catalog and a few added lines to glade_gtk_widget_action_activate() in glade-gtk.c) The hard part is the IPC, but since were not doing really time critical stuff then synchronization shouldnt be a problem. Anyway... let me know what you think... _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
