gmane.comp.desktop.xfce.devel.version4

Re: Panel widgets library

Harald Judt — 2012-05-19T09:01:52

Hi,

Am 19.05.2012 06:24, schrieb Andrzej:

After looking and hacking at various plugins, I can only confirm what 
Andrzej says about consistency and duplication. For example, when 
switching to the vertical mode, how should the plugins behave? 
systemload, netload, cpugraph, diskperf,... some of them handle the 
orientation differently than others. In this mode, some look similar to 
how they're expected to look in deskbar mode (I guess because it's new 
and was not available before and the authors decided this way of 
presentation was better), but some rotate their widgets to the right. 
What if the users expect them to be rotated to the left and arranged 
from the bottom to the top instead of from the top to the bottom? It's 
not supported at the moment and certainly a matter of taste and perhaps 
a bit too wide of scope.

I've seen there are some detailed guidelines at 
http://wiki.xfce.org/dev/hig/panel-plugins, that's already a good start. 
I wonder when those have been published... How about propagating those 
guidelines when you make announcements of a new panel release?

Currently, I wouldn't use the deskbar mode because many plugins I use 
don't handle this new feature correctly. This is unfortunate, because I 
find it really useful on today's widescreen panels. Maybe Andrzej's 
proposal could help here to speed up plugin development and adjustments 
in the future?

Now, since such things are on the table, here is some other idea which I 
thought about a few days ago:

I'm currently trying to improve some panel plugins that I use. Recently 
I've noticed there's a powersaving option in the systemload panel 
plugin, which reduces the plugin update interval when on battery. Now 
that's a good idea for laptop users, and I think it would be consistent 
and more effective if other panel plugins had such an option too.

However in that case I wonder if it wouldn't be better to integrate such 
an option in the panel itself, and make the other plugins read that 
value instead of creating their own widgets. That way, there would be a 
central place for controlling this setting, easy to adjust for the user. 
Additionally, the panel plugins wouldn't need to have their own widgets, 
they only had to implement appropriate upower code to decide aobut the 
appropriate update interval. Maybe that update could even be synchronous 
across all plugins? I don't know if that could be useful, but the 
consideration is wouldn't it be more effective if they all wake up at 
the same time?

In my opinion, many panel plugins could use this:
- systemload-plugin (already has its own option)
- netload-plugin
- diskperf-plugin
- weather-plugin
- wavelan-plugin
- cpugraph-plugin
- ...

What's your opinion on this? Do you think the energy savings would be 
noticeable and worth the effort? If yes, could the option be centralized 
or should the plugins handle it all on their own, like they are left to 
do currently?

Harald

Panel widgets library

Andrzej — 2012-05-19T04:24:36

I've been thinking about what we can do to improve quality and 
portability of panel plugins (which isn't exactly our strongest point).

Here is one idea:

- split libxfce4panel into two libraries:
   1. libxfce4panel, containing only stuff necessary for talking to the 
panel,
   2. libxfce4panel-widgets (pick your name) - containing additional 
panel-related stuff (panel image, hvbox, new widgets[1]) and is portable 
across panel versions.

Reasons:

- Non-core plugins are expected to be portable across Xfce versions. But 
because they depend on libxfce4panel, it is very difficult to add new 
functions this library - any new features have to be used conditionally, 
which requires changing all the plugins.
- libxfce4panel-widgets could evolve independently from the panel and be 
backward compatible with previous panel/Xfce versions.
- (why not simply use libxfce4ui) the new library would depend on 
libxfce4panel.

[1] we could for example provide a basic plugin widget, which could be 
inserted in the plugin and handle all the resizing, orientation, HIG 
stuff. Currently plugins are rather buggy and inconsistent in this area. 
Plugins that do this stuff right, reimplement the same functionality 
over and over.

Andrzej

Re: First gtk3 results

Auke Kok — 2012-05-18T04:44:13

yes, but, I'd rather use a half-assed C implementation to do something 
trivial like that in Python ;^)

Auke

Re: First gtk3 results

Nick Schermer — 2012-05-16T15:37:14

Ran awk '/Pss:/{ sum += $2 } END { print sum }' /proc/$(pidof 
thunar)/smaps

for Thunar gtk2 this gives 10908, for gtk3 14524

Nick

Ps, ps_mem also uses the Pss value from smaps.

Re: First gtk3 results

Auke Kok — 2012-05-16T03:40:03

can you post PSS usage?

you can get Pss from /proc/<pid>/smaps. Add all the rows that start with 
Pss: up. There's a tool called 'memuse' around that does it for you.

Auke

Re: First gtk3 results

Nick Schermer — 2012-05-15T20:43:57

Thunar is now also working in gtk3, or at least, parts of it 
(exo-icon-view is not working). Results are more or less equal: a size 
difference of ~2.5 MiB. Independent of the number of files used.

  7.2 MiB +   2.1 MiB =   9.3 MiB thunar (gtk3, 15 files)
  5.2 MiB +   1.5 MiB =   6.7 MiB thunar (gtk2, 15 files)

10.9 MiB +   2.1 MiB =  13.1 MiB thunar (gtk3, 1680 files)
  9.1 MiB +   1.5 MiB =  10.6 MiB thunar (gtk2, 1680 files)

The shared size will also drop a bit more if we port more gtk3 apps 
that use the xfce libraries.

Speed feels more or less the same (hard to measure that on an i7 ;-).

Nick

Getting started with development, helping out the project

Zsolt Peter Basak — 2012-05-14T07:56:31

Dear XFCE4-dev mailing list subscribers!

I have decided to help out the project, as I want to gather more
experience, and want to make XFCE better. First, I'm pretty sure that
one can't just jump into the middle of coding, there is a road to
that. The first thing I've done after checking the website, was
looking through the "Getting Involved" information. Sadly, the
development and bug fixing part is pretty short, not that informative.

So I would like to ask you. How could I start helping out the project?
Like sorting out bugs, reviewing them, mark them for review/close, and
so on.

Thanks in advance.
Best regards,
(john- on IRC)

Typo in docs.xfce.org

Masato Hashimoto — 2012-05-12T03:31:22

Hi,

There is a typo in http://docs.xfce.org/xfce/xfce4-session/advanced.
(due to the docwiki syntax).


'--' is replaced with '–' in '--with-ck-launch'.

Thx

Revive panel plugins HIG

Landry Breuil — 2012-05-08T19:38:26

Hi,

i'd like to revive/finish the discussion about panel plugins HIG that
started here : http://wiki.xfce.org/de/panel-hig (i suppose de was
meant to be 'dev') and seems to have resulted in
https://wiki.xfce.org/dev/hig/panel-plugins, but apparently not all
information was merged here. I've added a section about the new
features/possibilities given by panel 4.10 here :
https://wiki.xfce.org/dev/hig/panel-plugins?&#panel_properties . That
chunk is to be discussed here on the ml, on the wiki or on irc..

Now there are so many configuration possibilities (size * mode *
nrows..), and so many different levels of maintained plugins that it
becomes a real mess to get a consistent look & behaviour between
various plugins. I've started revamping battery & diskperf plugin UI,
but if we manage to settle on something i'll happily modify the
plugins where i have write access so that they comply to some sort of
HIG.

Landry

Ps; this is not a 'please add your feature request here' mail.

xfce4-settings: Circular scrolling.

Peter de Ridder — 2012-05-08T18:11:21

Hi devs,

I created a feature branch for xfce4-settings. "peter/circularscrolling".
This branch includes an addition to the mouse settings to enable
circular scrolling.
Since this would give 4 options for scrolling I also changed the UI
from radio buttons to a combo box.

The technical implementation is a followed:
If circular scrolling is selected and horizontal scrolling isn't. The
synpatics settings "Synaptics Circular Scrolling" is set to 1 and
"Synaptics Circular Scrolling Trigger" is set to 0 (any edge).
If circular scrolling and horizontal scrolling is selected. The
synpatics settings "Synaptics Circular Scrolling" is set to 1,
"Synaptics Circular Scrolling Trigger" is set to 3 (right edge) and
"Synaptics Edge Scrolling" is set to [0 1 0] (Only horizontal
scrolling).

Does anyone have objections if I merge this into trunk?
I'm planning to merge this on Thursday.

Regards,
Peter

[RFC] [PATCH] Option to show blinking buttons from all workspaces inWindow Button

Mathieu Chouquet-Stringer — 2012-05-08T16:28:18

Hello,

[Resending as I used the wrong email for the list)

I think Xfce used to have this feature (a long time ago or maybe I'm just
confused) where you could have blinking buttons for urgent windows which
are not in your current workspace.

Right now, blinking buttons only works if (or'ed):
- the urgent window is in your current workspace
- you have the "Show windows from all workspaces or viewports" enabled

There's even a bug open regarding this issue:
https://bugzilla.xfce.org/show_bug.cgi?id=6150

I also recall the "blinking on all workspaces" code was removed as some
people didn't really appreciate this feature.  Specially given it wasn't
an option: it was the standard behavior, whether you'd like it or not.

I've never hacked Xfce or anything remotely gtk/X related so bear that
in mind when you read the following...

I've cloned xfce4-panel from git and created a patch to fix this.

Right now, it's an optional feature (disabled by default) called "Show
all blinking windows" (for a lack of creativity).

I certainly have to fix some styling issues (indenting in particular)
and to figure out how the whole i18n thing works but before I do this,
I'd like to get some feedback regarding this patch.  Namely:
- Would it be acceptable?
- Did I miss anything?  (of course I did but...)
- any other comments...

Thanks!

Stats:
 tasklist-dialog.glade |   13 +++++++++++++
 tasklist-widget.c     |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++----------
 tasklist.c            |    2 ++

diff --git a/plugins/tasklist/tasklist-dialog.glade b/plugins/tasklist/tasklist-dialog.glade
index db6db74..e6583d8 100644
--- a/plugins/tasklist/tasklist-dialog.glade
+++ b/plugins/tasklist/tasklist-dialog.glade
< at >< at > -293,6 +293,19 < at >< at >
                             <property name="position">1</property>
                           </packing>
                         </child>
+                        <child>
+                          <object class="GtkCheckButton" id="include-all-blinking">
+                            <property name="label" translatable="yes">Show all _blinking windows</property>
+                            <property name="visible">True</property>
+                            <property name="can_focus">True</property>
+                            <property name="receives_default">False</property>
+                            <property name="use_underline">True</property>
+                            <property name="draw_indicator">True</property>
+                          </object>
+                          <packing>
+                            <property name="position">0</property>
+                          </packing>
+                        </child>
                       </object>
                     </child>
                   </object>
diff --git a/plugins/tasklist/tasklist-widget.c b/plugins/tasklist/tasklist-widget.c
index 0f1991a..d0c6d7f 100644
--- a/plugins/tasklist/tasklist-widget.c
+++ b/plugins/tasklist/tasklist-widget.c
< at >< at > -94,7 +94,8 < at >< at > enum
   PROP_SHOW_WIREFRAMES,
   PROP_SHOW_HANDLE,
   PROP_SORT_ORDER,
-  PROP_WINDOW_SCROLLING
+  PROP_WINDOW_SCROLLING,
+  PROP_INCLUDE_ALL_BLINKING
 };
 
 struct _XfceTasklistClass
< at >< at > -155,6 +156,10 < at >< at > struct _XfceTasklist
   /* switch window with the mouse wheel */
   guint                 window_scrolling : 1;
 
+  /* whether we show blinking windows from all workspaces
+   * or only the active workspace */
+  guint                 all_blinking : 1;
+
   /* whether we only show windows that are in the geometry of
    * the monitor the tasklist is on */
   guint                 all_monitors : 1;
< at >< at > -460,6 +465,13 < at >< at > xfce_tasklist_class_init (XfceTasklistClass *klass)
                                                          TRUE,
                                                          EXO_PARAM_READWRITE));
 
+  g_object_class_install_property (gobject_class,
+                                   PROP_INCLUDE_ALL_BLINKING,
+                                   g_param_spec_boolean ("include-all-blinking",
+                                                         NULL, NULL,
+                                                         FALSE,
+                                                         EXO_PARAM_READWRITE));
+
   gtk_widget_class_install_style_property (gtkwidget_class,
                                            g_param_spec_int ("max-button-length",
                                                              NULL,
< at >< at > -536,6 +548,7 < at >< at > xfce_tasklist_init (XfceTasklist *tasklist)
   tasklist->show_handle = TRUE;
   tasklist->all_monitors = TRUE;
   tasklist->window_scrolling = TRUE;
+  tasklist->all_blinking = FALSE;
   xfce_tasklist_geometry_set_invalid (tasklist);
 #ifdef GDK_WINDOWING_X11
   tasklist->wireframe_window = 0;
< at >< at > -622,6 +635,10 < at >< at > xfce_tasklist_get_property (GObject    *object,
       g_value_set_boolean (value, tasklist->window_scrolling);
       break;
 
+    case PROP_INCLUDE_ALL_BLINKING:
+      g_value_set_boolean (value, tasklist->all_blinking);
+      break;
+
     default:
       G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
       break;
< at >< at > -692,6 +709,10 < at >< at > xfce_tasklist_set_property (GObject      *object,
       tasklist->window_scrolling = g_value_get_boolean (value);
       break;
 
+    case PROP_INCLUDE_ALL_BLINKING:
+      tasklist->all_blinking = g_value_get_boolean (value);
+      break;
+
     default:
       G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
       break;
< at >< at > -2220,7 +2241,9 < at >< at > xfce_tasklist_button_visible (XfceTasklistChild *child,
       || (active_ws != NULL
           && (G_UNLIKELY (wnck_workspace_is_virtual (active_ws))
               ? wnck_window_is_in_viewport (child->window, active_ws)
-              : wnck_window_is_on_workspace (child->window, active_ws))))
+              : wnck_window_is_on_workspace (child->window, active_ws)))
+      || (tasklist->all_blinking
+  && xfce_arrow_button_get_blinking (XFCE_ARROW_BUTTON (child->button))))
     {
       return (!tasklist->only_minimized
               || wnck_window_is_minimized (child->window));
< at >< at > -2444,6 +2467,7 < at >< at > xfce_tasklist_button_state_changed (WnckWindow        *window,
   gboolean       blink;
   WnckScreen    *screen;
   XfceTasklist  *tasklist;
+  WnckWorkspace *active_ws;
 
   panel_return_if_fail (WNCK_IS_WINDOW (window));
   panel_return_if_fail (child->window == window);
< at >< at > -2490,11 +2514,26 < at >< at > xfce_tasklist_button_state_changed (WnckWindow        *window,
   if (PANEL_HAS_FLAG (changed_state, WNCK_WINDOW_STATE_DEMANDS_ATTENTION)
       || PANEL_HAS_FLAG (changed_state, WNCK_WINDOW_STATE_URGENT))
     {
-      /* only start blinking if the window requesting urgentcy
+      /* only start blinking if the window requesting urgency
        * notification is not the active window */
       blink = wnck_window_or_transient_needs_attention (window);
       if (!blink || (blink && !wnck_window_is_active (window)))
+{
+  /* if we have all_blinking set make sure we toggle visibility of the button
+   * in case the window is not in the current workspace */
+          active_ws = wnck_screen_get_active_workspace (child->tasklist->screen);
+  if (child->tasklist->all_blinking && blink
+      && !xfce_tasklist_button_visible (child, active_ws))
+    {
+      gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (child->button), FALSE);
+      gtk_widget_show (child->button);
+    }
+
           xfce_arrow_button_set_blinking (XFCE_ARROW_BUTTON (child->button), blink);
+
+  if (child->tasklist->all_blinking && !xfce_tasklist_button_visible (child, active_ws))
+    gtk_widget_hide (child->button);
+}
     }
 }
 
< at >< at > -2776,9 +2815,12 < at >< at > xfce_tasklist_button_activate (XfceTasklistChild *child,
   else
     {
       /* we only change worksapces/viewports for non-pinned windows
-       * and if all workspaces/viewports are shown */
-      if (child->tasklist->all_workspaces
-          && !wnck_window_is_pinned (child->window))
+       * and if all workspaces/viewports are shown or if we have
+       * all blinking enabled and the current button is blinking */
+      if ((child->tasklist->all_workspaces
+          && !wnck_window_is_pinned (child->window)) ||
+  (child->tasklist->all_blinking
+  && xfce_arrow_button_get_blinking (XFCE_ARROW_BUTTON (child->button))))
         {
           workspace = wnck_window_get_workspace (child->window);
 
diff --git a/plugins/tasklist/tasklist.c b/plugins/tasklist/tasklist.c
index 8f12f5c..1780344 100644
--- a/plugins/tasklist/tasklist.c
+++ b/plugins/tasklist/tasklist.c
< at >< at > -140,6 +140,7 < at >< at > tasklist_plugin_construct (XfcePanelPlugin *panel_plugin)
     { "show-handle", G_TYPE_BOOLEAN },
     { "sort-order", G_TYPE_UINT },
     { "window-scrolling", G_TYPE_BOOLEAN },
+    { "include-all-blinking", G_TYPE_BOOLEAN },
     { NULL }
   };
 
< at >< at > -252,6 +253,7 < at >< at > tasklist_plugin_configure_plugin (XfcePanelPlugin *panel_plugin)
   TASKLIST_DIALOG_BIND ("show-handle", "active")
   TASKLIST_DIALOG_BIND ("sort-order", "active")
   TASKLIST_DIALOG_BIND ("window-scrolling", "active")
+  TASKLIST_DIALOG_BIND ("include-all-blinking", "active")
 
 #ifndef GDK_WINDOWING_X11
   /* not functional in x11, so avoid confusion */

Re: cleaning up xfce-dev-tools

Natanael Copa — 2012-05-08T14:25:53

On Tue, 08 May 2012 15:27:16 +0200
Nick Schermer <nick< at >xfce.org> wrote:



Not that I know.

I was more thinking of a cleanup as in remove code that does not really
need to be there.

-nc

Re: cleaning up xfce-dev-tools

Natanael Copa — 2012-05-08T14:13:04

On Tue, 08 May 2012 13:20:33 +0000
Jannis Pohlmann <jannis< at >xfce.org> wrote:
 

1) Because I have wanted to contribute to xfce long time. But every time
i get demotivated but the .in.in. Its just so ugly and does not inspire
to write clean and efficient code. (autotools is ugly enough)

2) Packagers once in a while need to patch things. When patching the
general rules are:
* If upstream has fixed the issue, use that patch rather than reinvent.
* Don't patch generated code. Fix the stuff that generates code.
* Get you patch accepted upstream
  - send them a patch they simply can apply at first sight without any
    rework (otherwise the reported bug tend to remain unresolved for
    much longer time)

None of those are possible when configure.in.in is involved.

3) I like clean and efficient code.


Ok. That makes it easy.

Please at least ship the .in.in files with the tarballs.

-nc

Re: cleaning up xfce-dev-tools

Nick Schermer — 2012-05-08T13:27:16

Is there a case where the released packages are broken?

Nick

Re: cleaning up xfce-dev-tools

Jannis Pohlmann — 2012-05-08T13:20:33

On Tue, 8 May 2012 15:02:09 +0200, Natanael Copa <ncopa< at >alpinelinux.org>
wrote:

First and foremost I'd like to hear *why* you feel an "urgent need"
to do this and what is bothering you about the .ac.in, .in.in files.

With no good reasons provided I think your "how do you want it
to work?" question is easily answered with: exactly the way it works
at the moment. ;)

  - Jannis

cleaning up xfce-dev-tools

Natanael Copa — 2012-05-08T13:02:09

Hi,

I feel an urgent need to clean up xfce-dev-tools a bit and get
completely rid of the .{ac,in}.in. Only use .ac (or .in).

I could probably help with cleaning things up but I need to know:
How do you guys want it to work?

I know you want git version string baked into the version string
without editing configure.ac every commit and I know you want the
LINGUAS stuff be dynamic and I have some ideas.

Any suggestions for an API? (we need be backwards compat so we dont
break existing configure.in.in)

While here, maybe replace XDT_CHECK_PACKAGE with PKG_CHECK_MODULE too
(or reimplement XDT_CHECK_PACKAGE to use PKG_CHECK_MODULE)?

Thanks!

-nc

Systemd / Udev (was: [Xfce 4.12] Roadmap and Features)

Raphael Groner — 2012-05-08T12:58:19

Johannes Lips johannes.lips at googlemail.com 
Mon May 7 23:26:19 CEST 2012

Xfce 4.12 maybe has to remove ConsoleKit/PolicyKit, and later udev …

We promototed those features at CLT 2012 for Xfce 4.8 (and coming Xfce
4.10). The world is ruling faster and faster, features are coming,
features have to go in favour of new ones. Some questions would stay
what's a bug in that case. Udev is going to be implemented into Systemd
sources, at least for now already what decisions belong to upstream
development and VCS.


+1

This is a good argument to start forks that nobody needs. I don't want
to mention a special distributions branch or any direction of
evangelism.


No problem. It's a free world with free minds. :)

- Raphael

_______________________________________________
Xfce4-dev mailing list
Xfce4-dev< at >xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-dev

Re: [Xfce 4.12] Roadmap and Features

Raphael Groner — 2012-05-08T12:47:33

Maximilien Noal noal.maximilien at gmail.com 
Tue May 8 13:50:25 CEST 2012

On 05/06/2012 11:47 PM, Guido Berhoerster
wrote:
Good. Because I do not want systemd or PulseAudio on my Arch...

+1

As others and me have mentioned already here on the ML and in the RFE
bug report [0], support for Systemd should stay optional, however these
could be solved technically. Please try to stay as undependend as
possible! That was a main reason for me to use Xfce in past. :)

[0] https://bugzilla.xfce.org/show_bug.cgi?id=8729

Re: [Xfce 4.12] Roadmap and Features

Maximilien Noal — 2012-05-08T11:50:25

Good. Because I do not want systemd or PulseAudio on my Arch...

Re: [Xfce 4.12] Roadmap and Features

Natanael Copa — 2012-05-08T11:21:10

On Mon, 07 May 2012 12:51:56 +0200
Nick Schermer <nick< at >xfce.org> wrote:
 

When it comes to gtk3 memory usage it would be nice to know:
* Are there any difference in gtk 3.0 and 3.4? (getting better or worse)
* Why does gtk3 use so much more memory compared to gtk2?
* What would it take to "fix" gtk3? Are the upstream devs working on it
  or they don't care?
* Is there something that can be done to reduce memory usage when
  porting applications?

As a distro builder I would prefer to not need both gtk2 *and* gtk3
because that would eat more memory than only using gtk3. The number of
applications not supporting gtk2 is increasing. Already for xfce-4.10 I
found it slightly inconvenient with gtk2.

-nc

Re: [Xfce 4.12] Roadmap and Features

Johannes Lips — 2012-05-07T21:26:19

This was just an example where functionality was removed for BSD Users 
because Xfce switched to udev and removed HAL.
I did not say that Xfce should only support systemd and drop support for 
all other existing platforms, but only wanted to show that there were 
situations in the past were Xfce moved some things to linux-only.
I am fully aware that optional support for all existing init-systems and 
frameworks for session management and permissions.
Sorry if I sounded too blunt!



Johannes