Re: [PATCH 0/6] A few bug fixes and one minor improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/10/2013 22:36, Daniel Déchelotte wrote: > On Sat, 19 Oct 2013 Rodolfo García Peñas wrote: > >> - Push and hold Alt key - Click on the docked app - Detach it >> from the Clip (continue holding the Alt key and the mouse >> button) >> >> Now, if you try to attach it again, you can't! You must release >> the Alt key and then push it again to attach the icon again >> (don't release the mouse button). >> >> With the old behavior, when you hold the Alt key and detach the >> icon, then, the shadow is painted and the icon is ready to be >> attached to the Clip or the Dock. > > Alright, so we are talking of the same thing, but disagreeing on > what factually happened in the old behavior :). I maintain that, in > the old Nice :-) > > If the mouse button is released while Alt is pressed (and after > the mouse is moved a bit :-/), you are in step 3 above: no docking. > If Alt is no longer pressed, step 5, docking is possible. > > This is what I observed in wmaker-0.95.1 (Jan 2013). > > Do you repro the "I can move an appicon from a dock to another with > Alt pressed" behavior with that version? Ok, forget all. What should be the rigth behavior? 1. Alt button always pressed detatch and attach the icon? 2. Alt button pressed detach the icon + released attach it again? I don't know if the wmaker-0.95.1 (Jan 2013) version was option 1 or option 2. I think the original behavior was option 1, but I am not sure now. But... what we want now? Thanks Daniel! kix > -- Daniel > - -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSY9haAAoJEHsfVJByt0kjhjkP/1Zf8vyE6TqYL5kw1X0EzDwy HIOvrVX8rW6LnMWXDUc0RLwaT+w5Lyfzocgmdxq0/i5Zz4Z+lWh3ZdSqL0AFkdcI 3LiFO/ya7y/fGc8AMS7Q8Juay3Pzx5fOs0LxrFeK9lBB7zhr+HVEis1LIiGHhkb+ E3Fz2L2Rg59B79B43zHOmJ4Ipk59BIFeaNtAfQ72Qp4tV1cg5awKyougbaQHxb5j ePCivi+IVQEk7vHmEOBAfccWb999KJEqNCP/h5B42OPP+OULToo1SBViRTjlRz+o NtWlEC1JAipeZ28yH0BgPtJxeQCrQK62FEKeFRbBPUfyn6nLMBXqQ65YYX11Iaru Bv7+l3DJoJfLoYXz+MsmKvwYduhQFD32Y0gk+7tn2SGdXlIqhw7D4lVlktYlozhr cmk1j15r5b7eAv4Hx29Dxw+wSi1h+FsGP5dhuG7viaOwtMulygBAVEQ3x1Y8P/Ty q1bq8cMBn3ZoEdaOh5THBRe+CcMPTcdxavUeNvEEZli4JD78yohECZeTBkDiNqfD g4rFQM+WCQmR0Ux4ZjqTda3st32RjBFBpIaj2/q/xhAg2ZpYp3/8f2m2PSLVSX62 R5ZcbHB1eUraqqtbf2Pj2OBsYnOQ2/gwP3JkYxWzfWSkhVwTOqDjXGp3+CFIftR4 dgIRrBuLZROLLKGKNM7K =YAuq -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH 00/38] Help needed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was thinking about this... Probably is better that more people try to solve the XRandR problem. New ideas, new points of view. Perhaps we should think about create the object, and then "add" the screens to it. If we plug a new monitor, we add a new screen to the objects, if we unplug the monitor, we remove the screen. I don't know. I will stop here some days. Ideas are welcome. Cheers, kix - -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSY9ZUAAoJEHsfVJByt0kj6TQP/0vD3C4D0V/iZG5YdJfrhwb7 Q4Bx1LKey1EGV0RmR9puO1OF9dXuIVSZXLDw2lkv/1a9YrLmX4uixijDCZxdGcYs dSYfVdnGbtToVYod9DLE2XrHveEyqJwc9mxe54mAVWHCfxsESCQRML541AK012uT KCNIGUn6AWlQQPIDvRjis2x0MkL2dhAuJoUXNTPwEExEe92tpOtmXH9MBk0XCK4I CZ0jgKQt6c7YgvJweWn1/oj7SKbOU7Zsa9Vm89YSeJcLLapRT15BPLj7T4d82fOZ s28Pzav3QVS5DMg1oMEIFMy1QwPIe9nFWmcfEKDC1O+lz4i/XVX+8nL/LjYnODiR x0NDT6Pm9hiqtEVXQpuyh+4Gjy2cZF6YUXSE5/Q4U5z/lEFzA8DIRVYjuvWUkpLa zfagrhP8tRNJe7jfA3uly4UtQh6W0fzi0l5+bMBoumqnhLE66USMoHnTt78g7iW7 6kO9kYT/ikL0jaPGrWsDDcYUEU+hrIa19e8jqbTOuMPv9B0cIndg/d0hSlcDCHrA /cdPJJ6g8Wkt5LYjDRxmy1MXK3pTu2w5/MxwQP8UXuMwJM/RbunQ29x56tW0oqBh ionfy8ptmTbWzizVMWIZl4alq1NjONIZowTCkbJlHd0Jqgq7krly71iPlQPu/H+H jZb1Ub4LsfqRaovZ/DBA =xxsJ -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH 00/38] Help needed.
On Sun, 20 Oct 2013, Rodolfo García Peñas wrote:
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).
What if you move the XMapWindow call from mainIconCreate and place it
after the XMoveWindow call? Then the icon is not mapped until it's at the
correct position.
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<---
Maybe it's not painted but it may be cached by the X server or it needs to
be converted to the visual of the screen so if you have multiple screens
with different visuals then you'll probably need multiple instances for
the same icon for different screens. It does not matter if you load the
icon image into memory first and then instantiate it on different screens
or you just load it from disk (actually the OS will cache it for you) and
instantiate it when needed. So I don't see the advantage in trying to
cache it ourselves when it cannot save the multiple instances for
different screens.
Regards,
BALATON Zoltan
Re: Re : [PATCH 00/38] Help needed.
On Sun, 20 Oct 2013, Rodolfo García Peñas wrote: Ok, but then wmaker cannot be portable. I would like run wmaker on my Android. Create the things, and map in the X11, Android, Windows,... What do you want to use Window Maker for on Windows on Android? Its task is to manage windows and running applications on X. Where there's no X there's no need for an X Window Manager. Where an X window manager is useful it's no problem to depend on X Window System. Did I miss something? Regards, BALATON Zoltan
Re: Re : [PATCH 00/38] Help needed.
On Sun, 20 Oct 2013, BALATON Zoltan escribió: > On Sun, 20 Oct 2013, Rodolfo García Peñas wrote: > >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. > > Given that it is a Window Manager for X it is not surprising (or a > bad thing) that it depends on X. If X is deprecated there won't be > much use for an X Window Manager either so that's not a problem. Ok, but then wmaker cannot be portable. I would like run wmaker on my Android. Create the things, and map in the X11, Android, Windows,... > Therefore you won't be able to completely get rid of X dependency. > At most you may be able to split X independent and X dependent > parts, but given that the X independent parts have no use without > the others, it would just add complexity without any gain. So IMO > it's questionable if it worth it. > > Regards, > BALATON Zoltan -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH 00/38] Help needed.
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) 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 do
Re: [PATCH v2] Updated default icons
On Sat, 19 Oct 2013, Doug Torrance wrote:
diff --git a/WindowMaker/Defaults/WMWindowAttributes.in
b/WindowMaker/Defaults/WMWindowAttributes.in
index 41dedf8..f182e51 100644
--- a/WindowMaker/Defaults/WMWindowAttributes.in
+++ b/WindowMaker/Defaults/WMWindowAttributes.in
@@ -2,82 +2,6 @@
Logo.WMDock = {Icon = GNUstepGlow.#extension#;};
Logo.WMPanel = {Icon = GNUstep.#extension#;};
Logo.WMClip = {Icon = clip.#extension#;};
- Dockit = {Icon = GNUstep.#extension#;};
- DockApp = {NoAppIcon = NO;};
- panel.Panel = {NoAppIcon = YES;};
[...]
- Kinput2 = {
- NoTitlebar = Yes;
- NoResizebar = Yes;
- NotClosable = Yes;
- NotMiniaturizable = Yes;
- KeepOnTop = Yes;
- Omnipresent = Yes;
- SkipWindowList = Yes;
- NoHideOthers = Yes;
- NoKeyBindings = Yes;
- NoMouseBindings = Yes;
- KeepInsideScreen = Yes;
- NoAppIcon = Yes;
- Unfocusable = Yes;
- DontSaveSession = Yes;
- };
[...]
- kjobviewer = {
-SkipWindowList = Yes;
-DontSaveSession = Yes;
-Unfocusable = Yes;
-NoAppIcon = Yes;
- };
- kio_uiserver = {NoAppIcon = Yes;};
- kcmshell = {NoAppIcon = Yes;};
- kded = {NoAppIcon = Yes;};
Although I don't use any of them, I don't know if it's a good idea to
remove sensible defaults for parts of common desktop environments like a
panel or an input manager. People using those environments could have a
bad initial experience like appicons overlapping or hiding behind a
panel, appicons for input windows or similar.
Regards,
BALATON Zoltan
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH 00/38] Help needed.
On Sun, 20 Oct 2013, Rodolfo García Peñas wrote: 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. Given that it is a Window Manager for X it is not surprising (or a bad thing) that it depends on X. If X is deprecated there won't be much use for an X Window Manager either so that's not a problem. Therefore you won't be able to completely get rid of X dependency. At most you may be able to split X independent and X dependent parts, but given that the X independent parts have no use without the others, it would just add complexity without any gain. So IMO it's questionable if it worth it. Regards, BALATON Zoltan
Re: Re : [PATCH 00/38] Help needed.
On Sun, 20 Oct 2013, Christophe wrote: - Rodolfo García Peñas (kix) a écrit : [...] 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) I had the same feeling about this. [...] 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). I agree as I wrote previously. Wasn't the split of some info into the global structure a step into this direction? I think there's some ambiguity in the terms or functions of some objects that needs to be sorted but I don't know where or what exactly. Regards, BALATON Zoltan
