Hi,
I was thinking about the current behavior. See these problems:
1. Icon possition.
The icon is created here (I removed lines that doesn't matter for the issue)::
---8<---
static WAppIcon *mainIconCreate(WScreen *scr, int type, const char *name)
{
int x_pos;
switch(type) {
case WM_CLIP:
btn = wAppIconCreateForDock(scr, NULL, "Logo", "WMClip",
TILE_CLIP);
x_pos = 0;
case WM_DOCK:
default: /* to avoid a warning about btn and x_pos, basically */
btn = wAppIconCreateForDock(scr, NULL, "Logo", "WMDock",
TILE_NORMAL);
x_pos = scr->scr_width - ICON_SIZE - DOCK_EXTRA_SPACE;
case WM_DRAWER:
btn = wAppIconCreateForDock(scr, NULL, name, "WMDrawer",
TILE_DRAWER);
x_pos = 0;
}
btn->x_pos = x_pos;
btn->y_pos = 0;
---8<---
And then, is mapped here:
---8<---
WDock *wDockCreate(WScreen *scr, int type, const char *name)
{
btn = mainIconCreate(scr, type, name);
dock->x_pos = btn->x_pos;
dock->y_pos = btn->y_pos;
XMoveWindow(dpy, btn->icon->core->window, btn->x_pos, btn->y_pos);
---8<---
We creates the icons at 0,0 and the move it to the rigth possition. Why?
Because we create the icon on the screen (mapped). IMO, the right code should
be something like:
static WAppIcon *mainIconCreate(int type, const char *name)
{
int x_pos;
switch(type) {
case WM_CLIP:
btn = wAppIconCreateForDock(NULL, "Logo", "WMClip", TILE_CLIP);
case WM_DOCK:
default: /* to avoid a warning about btn and x_pos, basically */
btn = wAppIconCreateForDock(NULL, "Logo", "WMDock",
TILE_NORMAL);
case WM_DRAWER:
btn = wAppIconCreateForDock(NULL, name, "WMDrawer",
TILE_DRAWER);
}
---8<---
---8<---
WDock *wDockCreate(WScreen *scr, int type, const char *name)
{
btn = mainIconCreate(type, name); <- Without the screen
dock_map(btn, x, y);
---8<---
This problem exists in all elements (docks, appicons, icons, menu, ...). Then,
when the screen is changed, window maker must to be restarted. Create elements
in 0,0 and move (hidden) to the right possition and then map, vs create the
elements (only in memory, without the screen) and paint them in the right
possition (then, when the screen changes, we can paint then in the right
possition again).
Think a bit about it. All things, all menues (workspace menu, clip menu, dock
menu,...) exist always (as lists of things), painted on the screen (hidden).
IMO, we should have these things, but not painted. We should paint the things
when the user needs them. Then, we don't need think about the screen when the X
configuration changes (add screens, remove screens, connnect the laptop to a
monitor,...), because the list doesn't changes.
2. Icons depends on the screen, always.
Why this function, that reads the icon from the database, needs the screen?
Because the icon is painted on the screen when is created. All things are
created on the screen, mapped, then we show them (or are hidden).
---8<---
void set_icon_image_from_database(WIcon *icon, const char *wm_instance, const
char *wm_class, const char *command)
{
file = get_icon_filename(wm_instance, wm_class, command, False);
if (file) {
icon->file = wstrdup(file);
icon->file_image = get_rimage_from_file(icon->core->screen_ptr,
icon->file, wPreferences.icon_size);
wfree(file);
}
}
---8<---
3. Boot process
Simply check the StartUp function, in startup.c. This code creates the screens
and then paint the things on them. Something like:
scrs = create_screens()
create_things(scrs)
IMO, the code should be:
create_things();
create_screens();
map_things_on_screens();
Then, if the screens changes, wmaker should do:
create_screens();
map_things_on_screens();
Why? Because the things don't change. For example, when I connect a new
monitor, the workspace menu changes? NO, the icon for the dock/clip/...
changes? NO Only changes the item possitions (x, y), but no the content.
Then, here is the problem:
#ifdef HAVE_XRANDR
if (w_global.xext.randr.supported...) {e
Shutdown(WSRestartPreparationMode);
Restart(NULL,True);
}
#endif
Perhaps, I am in the wrong way, but IMO one thing is the data, and other thing
is how to represent the data.
Cheers,
kix
On Sun, 20 Oct 2013, Rodolfo kix Garcia escribió:
> Hi,
>
> Thanks for reading my looong mail. The main problem (IMO) is that wmaker
> depends on X11. If X11 dies (is deprecated), wmaker will have problems.
>
> Cheers.
>
> On Sun, 20 Oct 2013, Christophe escribió:
>
> >
> > ----- Rodolfo García Peñas (kix) <k...@kix.es> a écrit :
> > > Hi,
> > >
> > > I was working on these patches, but I think is too much work for only one
> > > person. I need your help.
> > >
> > > What I am doing? I am working on abstraction. My aim is that the wmaker
> > > elements doesn't use the screen or other physical devices. The aim is
> > > create the object in memomy and map it on the screen only when is needed.
> > > Therefore, if we change the screen, we can "re-map" the object, but we
> > > don't need re-create the object (and then, restart windowmaker). This
> > > idea is needed for XRandR.
> >
> >
> > Hi,
> > A little remark here: I think XRandR probably doesn't need this.
> > Under X there may be more than 1 screen, but if it is the case they may not
> > have the same color depth, which is why it was historically not possible to
> > move windows across screen, and why wmaker currently have distinct icons
> > per screens.
> >
> > Now the added value brought by Xinerama and RandR was, with the constraint
> > that all screens have the same depth, to make the screens look like a
> > single one to the applications, so you could move windows across screens.
> > In this mode, wmaker will also create only 1 WScreen struct.
> >
> > When calling 'XineramaQueryScreens' or the more modern 'XRRGetScreenInfo'
> > you get the physical screens, but it should not turn into wmaker screens as
> > it is not what wmaker calls a screen too, for the historical reason above.
> >
> >
> > > [...]
> > >
> > > The second problem is the icon images. The icon should be screen
> > > independent, but sometimes is not possible.
> >
> > My personal feeling is that they *have* to be screen dependant. Icons are
> > meant to be displayed on a screen, so they need to be. Keeping a screen
> > independent version looks like a memory overuse for me (and images are
> > already the biggest memory consuming things)
> >
> >
> > > [...]
> > >
> > > Without these ideas, is very difficult (IMO impossible) implement XRandR,
> > > Multiheader, ... configurations.
> >
> > I think the problem is not taken for the right angle.
> > It is not the image loading and icon creation that should be split, it is
> > the WScreen information:
> > The legacy X screen info (basically: depth, the infos to convert the
> > image into X specific format) should be separated from physical screen info
> > (as returned by Xinerama and Xrandr, info like size of the screen and the
> > likes).
> >
> > But that's just my feeling...
> >
> > Christophe.
> >
> >
> > --
> > To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
>
> --
> ||// //\\// Rodolfo "kix" Garcia
> ||\\// //\\ http://www.kix.es/
>
>
> --
> To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
