Hi.
Tommi Komulainen ([EMAIL PROTECTED]) wrote:
> Essentially the change would be to introduce a new widget (maybe
> HildonWindow or something) that would replace current HildonAppView. The
> new widget would be a real GtkWindow / toplevel X window which will
> require code changes when migrating the the new API, but in the longer
> term, once we drop the old views, reduce overall complexity.
Yeah, the concept of multiple views in an app struck me odd. I can see
reasons for having multiple views, but I don't see what is the benefit
over having multiple "GtkWindows" aka HildonApps.
When we are talking about the ease of porting it should be possible
to hide the differences between native GTK and Hildon in some #defines,
like e.g. this:
window = g_object_new (
#ifdef HILDON
HILDON_TYPE_APP,
"app-title", "Sudoku",
#else
GTK_TYPE_WINDOW,
#endif
"type", GTK_WINDOW_TOPLEVEL,
"events", GDK_KEY_PRESS_MASK,
"title", "Sudoku",
NULL);
Of course it is a personal preference thing to #ifdef the whole call to
g_object_new(), but I think you see the point.
Right now the code has to dive into different codepaths for native GTK
vs. Hildon, so that hildon gets an appview into the window and the rest
of the UI gets packed into the appview, it would be cool to get rid of
that need.
> Below is a rough, unordered list of goals for (or because of) the new
> widget. Feel free to comment if you think there's something important
> missing:
Some random thoughts on the points you raise.
> * unmodified gtk+ applications using GtkWindows will be accessible
> through the task switcher
This cannot be solved by a new widget. This needs to be solved at the
taskswitcher-level, preferrably by implementing the relevant parts of
the freedesktop wm-spec standards. This will give you a list of the top
level windows and you then can retrieve the icons as provided by the
application.
> * porting from GtkWindows to the new API should be trivial to get
> the basic looks, not more complicated than currently to get the
> toolbars etc. look and feel as with AppViews
See above for an approach with #define, I think this is quite trivial.
If it would be necessary to have a different widget hierarchy it becomes
more of a hurdle.
> * the new API should be as similar (toolbars) as possible, or in
> places more sane (key handling, fullscreening) than with
> AppViews
Just from looking at the hildon header files: deprecate
hildon_appview_set_fullscreen() and use gtk_window_(un)fullscreen()
instead.
Yeah, I am aware that an appview is not a window, but this is something
that needs to be cleared up. It does not really make sense to have two
appviews that both belong to the same hildonapp (read GtkWindow) and one
is fullscreen and the other is not.
For me the semantics of having multiple appviews is more like a big
GtkNotebook with invisible tabs. If the individual appviews should
appear in the task switcher might depend on the application and might
need to use an additional method to inform the task switcher about the
appviews, the task switcher then probably should display the appviews in
a kind of menu. It confuses the heck out of me to see two globes in the
task switcher, click on the lower one and suddenly the upper one gets
active (yeah, I know it is not like that, but it looks like that).
Thats it for now - I'll followup if something else comes to my mind.
Oh yeah - GIMP-like coding style for the headerfiles and the code :-)
Bye,
Simon
--
[EMAIL PROTECTED] http://simon.budig.de/
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
