dockapps.git repo redesign question

[Alexey I. Froloff]

Hi, everyone!

As Fedora packager, I find it difficult to work with current
dockapps.git repo.  There was discussion about that couple of
months ago, let me remind key issues:

1. No releases for particular dockapps.  Yes, we have continuous
development, but package maintainers need release tarballs.
2. Dockapps uses different versioning schemes.  There is no way
to know version of a particular dockapp.

I'd suggest to move from repo.or.cz to github.

I have already registered dockapps organization at github.
Each dockapp will have its' own repository with own history (I
can do it) and tags.  We will have all github social features,
like forks, pull requests, issues and stuff.  Github also
provides tarball download features for all published tags that
will satisfy package maintainer.

What do you think?


P.S. I can keep history for each dockapp from Strip off version
numbers from dir name commit, or from the beginning of time.
The later needs a bit more work...

-- 
Regards,--
Sir Raorn.   --- http://thousandsofhate.blogspot.com/


signature.asc
Description: Digital signature

Re: dockapps.git repo redesign question

[Carlos R. Mafra]

On Wed,  3 Apr 2013 at 15:06:36 +0400, Alexey I. Froloff wrote:
 Hi, everyone!
 
 As Fedora packager, I find it difficult to work with current
 dockapps.git repo.  There was discussion about that couple of
 months ago, let me remind key issues:
 
 1. No releases for particular dockapps.  Yes, we have continuous
 development, but package maintainers need release tarballs.
 2. Dockapps uses different versioning schemes.  There is no way
 to know version of a particular dockapp.

What about using a unified dockapp version for all dockapps under
the repository?

Say that I tag the repo now as 'version 0.5' and all dockapps
will have the extra version 'dockapps v0.5' attached to them.

 I'd suggest to move from repo.or.cz to github.
 We will have all github social features,
 like forks, pull requests, issues and stuff.  Github also
 provides tarball download features for all published tags that
 will satisfy package maintainer.

I don't see that as really necessary. Apart from the pull request,
which is not really needed for dockapp patches unless someone
starts working with them as his/her dayjob and writing dozens of them,
repo.or.cz has the other features too (which nobody uses anyway too).

 I have already registered dockapps organization at github.
 Each dockapp will have its' own repository with own history (I
 can do it) and tags.  
 
 What do you think?
 

Having one repository for each dockapp is way too much overhead, IMO.

I won't have them all, for example. Simply because it's a pain to keep
track of them all and do 'git pull's etc.

And quite frankly, these unmantained dockapps which were ressurected
in dockapps.git are so small that not having the fine version
granularity for each of them makes sense.

I say it's much more efficient to say I'm using wmbiff and wmpager 
from dockapps version 0.5 then saying wmbiff version x.y and wmpager
version z.y and go to each repository and check things out individually.

It's _way_ more efficient to have them under the same repository.

 P.S. I can keep history for each dockapp from Strip off version
 numbers from dir name commit, or from the beginning of time.
 The later needs a bit more work...

Once one has more work to do, it is easier to fall behind and delay
stuff and make others wait for it.

When _I_ have to deal with inefficient work I run away screaming like mad.
So my approach is to always make sure that the work to do is optimized
as much possible so that I don't have to run.

And IMHO you seem to want to create a more inefficient workflow around
the already-not-loved-enough dockapps.

My views might be wrong of course and more opinions are welcome.


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: Problem with icons position

[Christian]

Am 02.04.2013 21:20, schrieb Rodolfo García Peñas (kix):
 On 09/01/2013 9:11, Christian wrote:
 Hi,

 using a laptop with 2 monitors.
 the complete screen size is: 3200x1200
 the left monitor (external) has: 1920x1200 (position 0 0)
 the right monitor (laptop) has: 1280x800 (position 1920x400)

 so I have unviewable area in upper right with a size of 1280x400 and
 my icons start just in this neverland. I can not see all of my icons,
 just the ones that will reach the viewable area of the right monitor.
 And to move the icons downwards I need to click on the 'top' icon, keep
 the mouse button pressed and then move it downwards.
 But how should I click on the top icon when I can't see it ?

 When I move the mouse to the neverland and do a right click to view
 the menu, this is automatically moved to the left (the viewable) area.
 So is it possible to do this with the ICONS, too ?

 Thanks in advance.
 Chris

 Hi,

 I understand your problem, but no why it happends. Is very interesting.

 In the code for menu, wmaker creates a WRect, and check the position. If
 is outside, move it inside.

 In the code for icons, wmaker creates a WArea, and check the position.
 If is outside, move it inside.

 If is wrong for icons, should be wrong for menu (or the functions are
 different and one is wrong).
For the menu it works, but not for icons. So code for icons seem not to
be ok.
Just my 2 cents ;)


 Ok, some questions.

 1. Are you using Xinerama or Virtual desktop (I think yes).
 2. Did you try with xrand?

 Can you try xrand, si something like (copy as script, or run it):

 8
 #!/bin/bash
 xrandr --output LVDS1 --mode 1280x800
 xrandr --output VGA1 --mode 1920x1200
 xrandr --output VGA1 --left-of LVDS1
 8

 I am running xrandr here without problems. You need restart windowmaker
 to move the icons to the right position. Then:

 3. Is ok with xrandr?

 Then, we will continue :-)
Where do I see if I am using xinerama or xrand ?
I attached my xorg.conf, perhaps it is helpful.

I will check it, when I am at my workplace again.
Then I will come back and report
Thank you so far
Cheers

-- 

Christian

   - Please do not 'CC' me on list mails.
  Just reply to the list :)

Der ultimative shop für Sportbekleidung und Zubehör

http://www.sc24.de


Section ServerLayout
Identifier aticonfig Layout
Screen  0  aticonfig-Screen[0]-0 0 0
EndSection

Section Module
EndSection

Section Monitor
Identifier   aticonfig-Monitor[0]-0
Option  VendorName ATI Proprietary Driver
Option  ModelName Generic Autodetecting Monitor
Option  DPMS true
EndSection

Section Monitor
Identifier   0-LVDS
Option  VendorName ATI Proprietary Driver
Option  ModelName Generic Autodetecting Monitor
Option  DPMS true
Option  PreferredMode 1280x800
Option  TargetRefresh 60
Option  Position 1920 400
Option  Rotate normal
Option  Disable false
EndSection

Section Monitor
Identifier   0-CRT1
Option  VendorName ATI Proprietary Driver
Option  ModelName Generic Autodetecting Monitor
Option  DPMS true
Option  PreferredMode 1920x1200
Option  TargetRefresh 60
Option  Position 0 0
Option  Rotate normal
Option  Disable false
EndSection

Section Device
Identifier  aticonfig-Device[0]-0
Driver  fglrx
Option  Monitor-LVDS 0-LVDS
Option  Monitor-CRT1 0-CRT1
BusID   PCI:1:5:0
EndSection

Section Screen
Identifier aticonfig-Screen[0]-0
Device aticonfig-Device[0]-0
DefaultDepth 24
SubSection Display
Viewport   0 0
Virtual   3200 3200
Depth 24
EndSubSection
EndSection

[PATCH] wmbiff: Update manual pages.

[Gabriel VLASIU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

I hope this patch is properly formated.


Sincerely,
Gabriel

- -- 

// Gabriel VLASIU
//
// OpenGPG-KeyID  : 44952F15
// OpenGPG-Fingerprint: 4AC5 7C26 2FE9 02DA 4906  24B2 D32B 7ED7 4495 2F15
// OpenGPG-URL: http://www.vlasiu.net/public.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBCgAGBQJRXFp6AAoJENMrftdElS8VlI4P/0d1dFAcLnZAMT81/mITI9lf
xZCZwtbrO5kvEHUnILFKzNETDcBFH8nJ0IGoN1hgfQNsJfV5Q9EEcZdLUXnUNhM3
0aP03/5SPzlP02XX4Sqwra+4C0+66qfmeoo4wKd44BbFDF3O/6qoeihC2jt1YwEc
wvQani99szjy+IATFWVf5nn9nHVzumjhd7nPoCAV0sH/F8Z1cDsLePbgLvmJeBCy
6bF6qRt3Q/TMEvi7eE3R0PhF2xA/mfzziCTwdbzYb/gyB5Svhibq2radt+gMf/IB
H/n1G2X82LHzqDqRzRRSZPRga3yzG8OWQqLg6mL6cAHEX6LJYWrMEaPldLxLY+q4
imUvDpej9i7V7j8Llkw1L6Ru63qBhxp5yvELJ9aM28WhvaqJwHrTAiSC4j+xBSi/
I1lKngnuTb62+SurgVrEX8r4yX6HVtKdOWHw3D9NFfCy1Y8uFShhtwulVnbjYVhX
H/dz7Q5SRCxU8kDos0UrVK1BXfhtJNtGV5MuMf3Tyt/I9vy2my1c8iyox9bRsvNU
faStiMNXREy4Ts8sPhltJJHJsBuVmvqQ4bXYEmjOPEAMIpb0/KCZsEuIpIqhKc8P
8KInubmWjiPX+itXLNv5mzZ0nJ80IhJ98nEwlDLfeY4GVNwsL8N6fYGWvpj7KE7I
0QV4jS/7ijMbME2xTpJf
=MI12
-END PGP SIGNATURE-From f2345ee2cf3f4c76d0b9f704beb0b7e600384cce Mon Sep 17 00:00:00 2001
From: Gabriel VLASIU gabr...@vlasiu.net
Date: Wed, 3 Apr 2013 19:26:57 +0300
Subject: [PATCH 1/1] Update manual for wmbiff and wmbiffrc.

---
 wmbiff/wmbiff/wmbiff.1  | 18 +++---
 wmbiff/wmbiff/wmbiffrc.5.in | 24 
 2 files changed, 11 insertions(+), 31 deletions(-)

diff --git a/wmbiff/wmbiff/wmbiff.1 b/wmbiff/wmbiff/wmbiff.1
index 4a70f2c..e3c1b26 100644
--- a/wmbiff/wmbiff/wmbiff.1
+++ b/wmbiff/wmbiff/wmbiff.1
@@ -13,7 +13,7 @@ WMBiff \- A dockable Mailbox Monitor
 
 .SH SYNOPSIS
 .B wmbiff
-[-display display name] [-geometry +XPOS+YPOS] [-c filename] [-h] [-v] 
[-debug] [-fg foreground-color] [-font X11 font|default] [-hi 
highlight-color] [+w]
+[-display display name] [-geometry +XPOS+YPOS] [-c filename] [-h] [-v] 
[-debug] [-fg foreground-color] [-bg background-color] [-hi 
highlight-color] [-font X11 font|default] [+w]
 .br
 
 .SH DESCRIPTION
@@ -61,8 +61,16 @@ Use specified configuration file instead of ~/.wmbiffrc.
 Print verbose log of progress.
 .TP
 .B \-fg color
-Use specified X11 color.  Implies -font default, unless 
-overridden.
+Use specified X11 color for foreground. Implies -font default,
+unless overridden.
+.TP
+.B \-bg color
+Use specified X11 color for background. Implies -font default,
+unless overridden.
+.TP
+.B \-hi color
+Use specified X11 color for new mail counters. Implies -font
+default, unless overridden.
 .TP
 .B \-font font
 Use specified X11 font instead of the LED pixmap.  This may
@@ -70,10 +78,6 @@ be more readable or suitable for some non-US characters.
 The special font default tells wmbiff to use a compile
 time default.
 .TP
-.B \-hi color
-Use specified X11 color for new mail counters.  Implies -font
-default, unless overridden.
-.TP
 .B \-skip-certificate-check
 When using TLS (IMAPS), keep going, even if the server's
 certificate is invalid.  Invalid certificates have expired,
diff --git a/wmbiff/wmbiff/wmbiffrc.5.in b/wmbiff/wmbiff/wmbiffrc.5.in
index 812c799..0443bc5 100644
--- a/wmbiff/wmbiff/wmbiffrc.5.in
+++ b/wmbiff/wmbiff/wmbiffrc.5.in
@@ -163,30 +163,6 @@ imaps:user:@server[/mailbox][:port] [auth]
 imaps:user passwd server[/mailbox][ port] [auth]
 .RE
 .TP
-.I licq
-With this box type, wmbiff will read the given history file and track the
-number of messages in it. It just needs a path to a given licq history file.
-.RS
-licq:/path/to/.licq/history/file.history
-.RE
-.TP
-.I gicu
-With this box type, wmbiff will ask gnomeicu for the number
-of pending messages.  If gnomeicu is not running, nothing
-will be displayed.  gnomeicu-client must be in your path.
-The user's icq UIN is optional.
-.RS
-gicu:[UIN]
-.RE
-.TP
-.I finger
-With this box type, wmbiff will finger an account to see if
-there is unread mail.  Both finger and perl must be in your
-path, and your server must run a finger daemon.
-.RS
-finger:user@host
-.RE
-.TP
 .I shell
 With this keyword, wmbiff will launch the
 specified shell command and read its output (STDOUT)
-- 
1.8.1.4

Re: [PATCH] wmbiff: Update manual pages.

[Carlos R. Mafra]

On Wed,  3 Apr 2013 at 19:36:10 +0300, Gabriel VLASIU wrote:
 
 I hope this patch is properly formated.

Thanks for the patch and yes, it was properly formated.
And because of _that_, I just needed a few key presses to
push it to the repository :-)

So your last patch is already there (the others not yet).


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

[PATCH 3/6] wGetRectForHead moved to where used

[kix]

From: Rodolfo García Peñas (kix) k...@kix.es

The definition and call for wGetRectForHead is moved inside the
if block where is used. This code adds a WScreen pointer to make
the line shorter.

If menu-frame is NULL, then was NULL before this patch, so this
code doesn't include an error about this.

This patch will used with next patch to move the code inside the
block to an specific function.
---
 src/menu.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/menu.c b/src/menu.c
index b770d4c..696daa0 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -1062,15 +1062,16 @@ static int keyboardMenu(WMenu * menu)
 
 void wMenuMapAt(WMenu * menu, int x, int y, int keyboard)
 {
-   WMRect rect = wGetRectForHead(menu-frame-screen_ptr,
- 
wGetHeadForPointerLocation(menu-frame-screen_ptr));
-
if (!menu-flags.realized) {
menu-flags.realized = 1;
wMenuRealize(menu);
}
+
if (!menu-flags.mapped) {
if (wPreferences.wrap_menus) {
+   WScreen *scr = menu-frame-screen_ptr;
+   WMRect rect = wGetRectForHead(scr, 
wGetHeadForPointerLocation(scr));
+
if (x  rect.pos.x)
x = rect.pos.x;
if (y  rect.pos.y)
-- 
1.7.10.4


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

[PATCH 5/6] New function get_right_position_on_screen

[kix]

From: Rodolfo García Peñas (kix) k...@kix.es

The function get_right_position_on_screen() sets the right position
in the screen using a WRect. It moves the x and y coordinates to the
right place.
---
 src/menu.c  |   16 +++-
 src/placement.c |   17 +
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/src/menu.c b/src/menu.c
index 696daa0..5a52d36 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -43,6 +43,7 @@
 #include workspace.h
 #include dialog.h
 #include rootmenu.h
+#include placement.h
 
 /** Global Variables **/
 
@@ -1068,19 +1069,8 @@ void wMenuMapAt(WMenu * menu, int x, int y, int keyboard)
}
 
if (!menu-flags.mapped) {
-   if (wPreferences.wrap_menus) {
-   WScreen *scr = menu-frame-screen_ptr;
-   WMRect rect = wGetRectForHead(scr, 
wGetHeadForPointerLocation(scr));
-
-   if (x  rect.pos.x)
-   x = rect.pos.x;
-   if (y  rect.pos.y)
-   y = rect.pos.y;
-   if (x + MENUW(menu)  rect.pos.x + rect.size.width)
-   x = rect.pos.x + rect.size.width - MENUW(menu);
-   if (y + MENUH(menu)  rect.pos.y + rect.size.height)
-   y = rect.pos.y + rect.size.height - MENUH(menu);
-   }
+   if (wPreferences.wrap_menus)
+   get_right_position_on_screen(menu-frame-screen_ptr, 
x, y, MENUW(menu), MENUH(menu));
 
XMoveWindow(dpy, menu-frame-core-window, x, y);
menu-frame_x = x;
diff --git a/src/placement.c b/src/placement.c
index 5e4a8e7..5a3eaa9 100644
--- a/src/placement.c
+++ b/src/placement.c
@@ -565,3 +565,20 @@ void PlaceWindow(WWindow *wwin, int *x_ret, int *y_ret, 
unsigned width, unsigned
if (*y_ret  usableArea.y1)
*y_ret = usableArea.y1;
 }
+
+void get_right_position_on_screen(WScreen *scr, int *x, int *y, int size_x, 
int size_y)
+{
+   WMRect rect = wGetRectForHead(scr, wGetHeadForPointerLocation(scr));
+
+   if (*x  rect.pos.x)
+   *x = rect.pos.x;
+
+   if (*y  rect.pos.y)
+   *y = rect.pos.y;
+
+   if (*x + size_x  rect.pos.x + rect.size.width)
+   *x = rect.pos.x + rect.size.width - size_x;
+
+   if (*y + size_y  rect.pos.y + rect.size.height)
+   *y = rect.pos.y + rect.size.height - size_y;
+}
-- 
1.7.10.4


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 2/6] code clean at startup.c

[Carlos R. Mafra]

On Wed,  3 Apr 2013 at 20:01:46 +0200, Rodolfo García Peñas (kix) wrote:
 From: Rodolfo García Peñas (kix) k...@kix.es
 
 Small code clean at startup.c
 ---
  src/startup.c |   16 ++--
  1 file changed, 6 insertions(+), 10 deletions(-)
 
 diff --git a/src/startup.c b/src/startup.c
 index e0249ee..f9d4e52 100644
 --- a/src/startup.c
 +++ b/src/startup.c
 @@ -415,16 +415,12 @@ WScreen *wScreenForRootWindow(Window window)
   if (wScreenCount == 1)
   return wScreen[0];
  
 - /*
 -  * Since the number of heads will probably be small (normally 2),
 + /* Since the number of heads will probably be small (normally 2),
* it should be faster to use this than a hash table, because
 -  * of the overhead.
 -  */
 - for (i = 0; i  wScreenCount; i++) {
 - if (wScreen[i]-root_win == window) {
 +  * of the overhead. */

I don't care too much about the multiline comment style, but FYI you're
deviating from what's supposed to be wmaker's coding style.

But as I said, I don't care too much. Applied.


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 5/6] New function get_right_position_on_screen

[Carlos R. Mafra]

On Wed,  3 Apr 2013 at 20:01:49 +0200, Rodolfo García Peñas (kix) wrote:
 From: Rodolfo García Peñas (kix) k...@kix.es
 
 The function get_right_position_on_screen() sets the right position
 in the screen using a WRect. 

This description confuses me a bit. The function is named get_ but it sets the
position, so it should be named set_, no?

 It moves the x and y coordinates to the right place.

So what's the _right_ in the name? It is 'right' as opposed
to 'left' or is it 'right' as 'correct'?

From my brief reading of the function, I think that dropping 
the 'right' from the name would not create confusion, or do
you envision having a set_left_position_on_screen()?

I don't know if I'm making sense, though :-)

 ---
  src/menu.c  |   16 +++-
  src/placement.c |   17 +
  2 files changed, 20 insertions(+), 13 deletions(-)
 
 diff --git a/src/menu.c b/src/menu.c
 index 696daa0..5a52d36 100644
 --- a/src/menu.c
 +++ b/src/menu.c
 @@ -43,6 +43,7 @@
  #include workspace.h
  #include dialog.h
  #include rootmenu.h
 +#include placement.h
  
  /** Global Variables **/
  
 @@ -1068,19 +1069,8 @@ void wMenuMapAt(WMenu * menu, int x, int y, int 
 keyboard)
   }
  
   if (!menu-flags.mapped) {
 - if (wPreferences.wrap_menus) {
 - WScreen *scr = menu-frame-screen_ptr;
 - WMRect rect = wGetRectForHead(scr, 
 wGetHeadForPointerLocation(scr));
 -
 - if (x  rect.pos.x)
 - x = rect.pos.x;
 - if (y  rect.pos.y)
 - y = rect.pos.y;
 - if (x + MENUW(menu)  rect.pos.x + rect.size.width)
 - x = rect.pos.x + rect.size.width - MENUW(menu);
 - if (y + MENUH(menu)  rect.pos.y + rect.size.height)
 - y = rect.pos.y + rect.size.height - MENUH(menu);
 - }
 + if (wPreferences.wrap_menus)
 + get_right_position_on_screen(menu-frame-screen_ptr, 
 x, y, MENUW(menu), MENUH(menu));
  
   XMoveWindow(dpy, menu-frame-core-window, x, y);
   menu-frame_x = x;
 diff --git a/src/placement.c b/src/placement.c
 index 5e4a8e7..5a3eaa9 100644
 --- a/src/placement.c
 +++ b/src/placement.c
 @@ -565,3 +565,20 @@ void PlaceWindow(WWindow *wwin, int *x_ret, int *y_ret, 
 unsigned width, unsigned
   if (*y_ret  usableArea.y1)
   *y_ret = usableArea.y1;
  }
 +
 +void get_right_position_on_screen(WScreen *scr, int *x, int *y, int size_x, 
 int size_y)
 +{
 + WMRect rect = wGetRectForHead(scr, wGetHeadForPointerLocation(scr));
 +
 + if (*x  rect.pos.x)
 + *x = rect.pos.x;
 +
 + if (*y  rect.pos.y)
 + *y = rect.pos.y;
 +
 + if (*x + size_x  rect.pos.x + rect.size.width)
 + *x = rect.pos.x + rect.size.width - size_x;
 +
 + if (*y + size_y  rect.pos.y + rect.size.height)
 + *y = rect.pos.y + rect.size.height - size_y;
 +}
 -- 
 1.7.10.4
 
 
 -- 
 To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: dockapps.git repo redesign question

[Rodolfo García Peñas (kix)]

On 03/04/2013 18:59, Alexey I. Froloff wrote:
 On Wed, Apr 03, 2013 at 06:03:09PM +0200, Rodolfo García Peñas (kix) wrote:
 I think that every dockapp should continue with their version number if
 the code doesn't change. I think dockapps repo is only to hold all
 applications together and avoid lost them.
 How do you suggest tracking dockapp versions?

IMO, I should use the version number included in the code by the last
person that make changes. If there are changes, but no new version, then
using the old version number, +git-date where date is mmdd.

 perhaps the script used to do the nightly package for wmaker (at debian
 folder) can help you to create the .tgz files. You can create the .tgz
 for every dockapp, with a new version, only if the revision change.
 What is that revision you are talking about?
 
 I've changed the code of wmfoo dockapp and decided to release
 version 0.4.18.  What's next?  How do I tag this release and make
 a tarball?

I don't know. Perhaps incluiding some file with the revision number.

 Next question: I want to make tarball for the newest version on
 wmbar dockapp.  Just checked out the dockapps repo.  How can I do
 that?

If you are uploading the .tgz to any place, then the package is there.

But, anyway. I think your idea is good (except I don't like github). If
you (or you and Carlos, or you Carlos and X (where X is not me [sorry,
but really, my time^H^H^H^H no time])) maintain the dockapps repo,
perfect. I only try to say that every dockapp is different, because are
different applications, and have different files and different file
tree. Perhaps, we should work in other direction, like change things to
make the dockapps with the same struct, include machine-readable
files,... I don't know.

I wrote in my notebook (paper):

- Create an script to make dockapps tgz's and upload to any place.
- Create a new dockapp library with the common code to do common (basic)
things, like:
  * Code to read the CPU (used by wmmon, wmcpumon,...)
  * Code to read the network interfaces (speed,...) used by multiple
dockapps too.

Because I am not doing it, because I am with other things, feel free to
do what you want. If you need help, and I can help you, I'm here.

One thing more, please hold only *one* repo for the dockapps.

Saludos,
kix
-- 
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 5/6] New function get_right_position_on_screen

[Rodolfo García Peñas (kix)]

On 03/04/2013 20:33, Carlos R. Mafra wrote:
 On Wed,  3 Apr 2013 at 20:01:49 +0200, Rodolfo García Peñas (kix) wrote:
 From: Rodolfo García Peñas (kix) k...@kix.es

 The function get_right_position_on_screen() sets the right position
 in the screen using a WRect. 
 
 This description confuses me a bit. The function is named get_ but it sets the
 position, so it should be named set_, no?
 
 It moves the x and y coordinates to the right place.
 
 So what's the _right_ in the name? It is 'right' as opposed
 to 'left' or is it 'right' as 'correct'?
 
 From my brief reading of the function, I think that dropping 
 the 'right' from the name would not create confusion, or do
 you envision having a set_left_position_on_screen()?
 
 I don't know if I'm making sense, though :-)

Sorry, correct.

This patches checks if the x,y inside the screen, using a rect.

Is something like:
is x is minor, is outside (left)
if x is greater, is outside (rigth)
...



 ---
  src/menu.c  |   16 +++-
  src/placement.c |   17 +
  2 files changed, 20 insertions(+), 13 deletions(-)

 diff --git a/src/menu.c b/src/menu.c
 index 696daa0..5a52d36 100644
 --- a/src/menu.c
 +++ b/src/menu.c
 @@ -43,6 +43,7 @@
  #include workspace.h
  #include dialog.h
  #include rootmenu.h
 +#include placement.h
  
  /** Global Variables **/
  
 @@ -1068,19 +1069,8 @@ void wMenuMapAt(WMenu * menu, int x, int y, int 
 keyboard)
  }
  
  if (!menu-flags.mapped) {
 -if (wPreferences.wrap_menus) {
 -WScreen *scr = menu-frame-screen_ptr;
 -WMRect rect = wGetRectForHead(scr, 
 wGetHeadForPointerLocation(scr));
 -
 -if (x  rect.pos.x)
 -x = rect.pos.x;
 -if (y  rect.pos.y)
 -y = rect.pos.y;
 -if (x + MENUW(menu)  rect.pos.x + rect.size.width)
 -x = rect.pos.x + rect.size.width - MENUW(menu);
 -if (y + MENUH(menu)  rect.pos.y + rect.size.height)
 -y = rect.pos.y + rect.size.height - MENUH(menu);
 -}
 +if (wPreferences.wrap_menus)
 +get_right_position_on_screen(menu-frame-screen_ptr, 
 x, y, MENUW(menu), MENUH(menu));
  
  XMoveWindow(dpy, menu-frame-core-window, x, y);
  menu-frame_x = x;
 diff --git a/src/placement.c b/src/placement.c
 index 5e4a8e7..5a3eaa9 100644
 --- a/src/placement.c
 +++ b/src/placement.c
 @@ -565,3 +565,20 @@ void PlaceWindow(WWindow *wwin, int *x_ret, int *y_ret, 
 unsigned width, unsigned
  if (*y_ret  usableArea.y1)
  *y_ret = usableArea.y1;
  }
 +
 +void get_right_position_on_screen(WScreen *scr, int *x, int *y, int size_x, 
 int size_y)
 +{
 +WMRect rect = wGetRectForHead(scr, wGetHeadForPointerLocation(scr));
 +
 +if (*x  rect.pos.x)
 +*x = rect.pos.x;
 +
 +if (*y  rect.pos.y)
 +*y = rect.pos.y;
 +
 +if (*x + size_x  rect.pos.x + rect.size.width)
 +*x = rect.pos.x + rect.size.width - size_x;
 +
 +if (*y + size_y  rect.pos.y + rect.size.height)
 +*y = rect.pos.y + rect.size.height - size_y;
 +}
 -- 
 1.7.10.4


 -- 
 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.

Re: dockapps.git repo redesign question

[Carlos R. Mafra]

On Wed,  3 Apr 2013 at 20:40:02 +0200, Rodolfo García Peñas (kix) wrote:
 
 One thing more, please hold only *one* repo for the dockapps.

If we can agree on that first, we can try to work out the rest.

But I also feel like having a central place for all these dockapps
is much better than having many scattered around.

Another thing to consider is why does it matter to have a version
for _each_ dockapp. 

The strongest reason I guess is to be able to refer to something
specific when complaining about them, like in  dockapp foobar
version x.y.z is not working.

If everybody agrees with that and all dockapps are inside the
same repo, then it's also easy to tag the repo and refer to that.

For example, I don't even know nor do I care about which version
'wmbiff' has right now. But I can say that it doesn't compile in the
current dockapps.git repo today with a recent gnutls lib. The label
to which I'm refering to is therefore the repo itself, not the dockapp.

So my implicit suggestion to distros wanting to have the dockapps from
dockapps.git is that they should package them in one package, not 41.

Say you put every dockapp under dockapps-repo-version.rpm and be done
with it. Would that work?




-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: dockapps.git repo redesign question

[Carlos R. Mafra]

On Wed,  3 Apr 2013 at 21:30:50 +0200, Rodolfo García Peñas (kix) wrote:
 On 03/04/2013 21:25, Carlos R. Mafra wrote:
  On Wed,  3 Apr 2013 at 20:40:02 +0200, Rodolfo García Peñas (kix) wrote:
 
  One thing more, please hold only *one* repo for the dockapps.
  
  If we can agree on that first, we can try to work out the rest.
  
  But I also feel like having a central place for all these dockapps
  is much better than having many scattered around.
  
  Another thing to consider is why does it matter to have a version
  for _each_ dockapp. 
  
  The strongest reason I guess is to be able to refer to something
  specific when complaining about them, like in  dockapp foobar
  version x.y.z is not working.
  
  If everybody agrees with that and all dockapps are inside the
  same repo, then it's also easy to tag the repo and refer to that.
  
  For example, I don't even know nor do I care about which version
  'wmbiff' has right now. But I can say that it doesn't compile in the
  current dockapps.git repo today with a recent gnutls lib. The label
  to which I'm refering to is therefore the repo itself, not the dockapp.
  
  So my implicit suggestion to distros wanting to have the dockapps from
  dockapps.git is that they should package them in one package, not 41.
  
  Say you put every dockapp under dockapps-repo-version.rpm and be done
  with it. Would that work?
 
 IMO, no. Probably I want have only some dockapps, not all.

My point is that it doesn't matter to much.

Say you want to use only wmpager. You install the dockapps package
and you also get other 40 dockapps that you didn't want, but is that
really important? They are so small!

IIRC, KDE games which would install a bunch of them. I think that
makes sense.

The same for wmaker dockapps. Why not install all of them in one go?
 
 But this is not incompatible with your idea. All dockapps can have the
 same version and I can have one meta-package dockapps or
 wmaker-dockapps with different packages (one per dockapp), and build
 all together.
 
 The reason because I don't like have the same version is because every
 dockapp is different, from different developers,... but, perhaps now is
 time to join them. Some of them are at the dockapps repo because are
 unmaintained, missing,... so perhaps we can change the version.

That's what I think makes more sense. We should think about the dockapps
from dockapps.git as a whole. Being too fine-grained will hurt because
that's mantainance overhead.

 One repo to rule them all.


-- 
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.