I don't think it's a terribly good idea to completely ban minimize while
we're still in a transition period.
I think Plank's current "hide/show" behavior makes sense for now and I'm
not terribly inclined to monkey with it too much for Luna.
We should revisit this in Luna +1 when we're more confid
Right that's why I said I don't doubt it should be changed xD
Best Regards,
Daniel Foré
El sep 20, 2012, a las 9:43 p.m., Cassidy James
escribió:
> Dan,
>
> The multi-display setup as-is is broken. If I maximize an app on a secondary
> display and there's no app on the primary display, the d
Dan,
The multi-display setup as-is is broken. If I maximize an app on a
secondary display and there's no app on the primary display, the dock
should *not* hide.
Regards,
Cassidy James
On Sep 20, 2012 11:19 PM, "Daniel Foré" wrote:
> I'm iffy on hiding the dock for *any* maximized window, but th
Rico,
The problem is that currently the theme is shared for all users, so you
would need admin privileges to adjust this. Definitely not desirable.
I've filed the bug here: https://bugs.launchpad.net/plank/+bug/1053801
On Thu, Sep 20, 2012 at 8:59 AM, Rico Tzschichholz wrote:
> Cassidy,
>
> Pla
I'm iffy on hiding the dock for *any* maximized window, but then again I
personally think Maximized apps should be all alone on their workspace (and
that's how I work) so it doesn't really affect me. I guess we'd have to ask
people who use unfocused, maximized apps :p
But I don't doubt that the mu
The only satisfying behavior I've found is to never hide the dock.
On Thu, Sep 20, 2012 at 5:33 PM, Florian Reifschneider <
flore2...@googlemail.com> wrote:
> I do agree on changing the multi-display behavior, but I think it would be
> irritating to hide the dock, if there is a maximized window o
Florian,
That's what I was wondering, too. I'm undecided about it still.
Regards,
Cassidy James
On Sep 20, 2012 5:33 PM, "Florian Reifschneider"
wrote:
> I do agree on changing the multi-display behavior, but I think it would be
> irritating to hide the dock, if there is a maximized window on t
I do agree on changing the multi-display behavior, but I think it would be
irritating to hide the dock, if there is a maximized window on the current
workspace with a not maximized window top of it that is focused.
I do like to see my dock for notifications and stuff if I'm for example
working in
Window dodge has been superseded by intellihide. Also, it's probably
important to note the _current_ Pantheon hiding behavior:
• Hide when the focused app is maximized.
This makes hiding and multiple displays iffy, as well as causing the
aforementioned issues.
On Sep 20, 2012 5:04 PM, "Harvey Cab
Never mind, I was thinking of window dodge.
Well, I don't think I would mind this change, +/- on it.
On Sep 20, 2012 5:00 PM, "Harvey Cabaguio" wrote:
> There was something like this on docky 2.0 no?
> On Sep 20, 2012 4:45 PM, "Cassidy James" wrote:
>
>> Rico (rockstar developer who's been acti
There was something like this on docky 2.0 no?
On Sep 20, 2012 4:45 PM, "Cassidy James" wrote:
> Rico (rockstar developer who's been actively helping in the departments of
> Gala and Plank) added a hide mode to our version of Plank that hides it
> when the focused app is maximized (which is set a
Rico (rockstar developer who's been actively helping in the departments of
Gala and Plank) added a hide mode to our version of Plank that hides it
when the focused app is maximized (which is set as the default behavior in
Luna). I've been using this and occasionally run into instances where the
doc
2012/9/21 Nishant Agrwal
> Okay, I think you're right. The dock's the correct place to start. How do
> you feel about losing explicit minimize though? Do you guys think you can
> live without it?
Why should we? Taking it away is way more work than leaving it in place, so
we'd better spend time
Thanks a lot Cody! 25 is more than the last time (23 IIRC).
On Thu, Sep 20, 2012 at 7:23 PM, Cody Garver wrote:
> I knew I forgot something, Files is there now too. That brings the total
> to 25 bugs.
>
> On Thu, Sep 20, 2012 at 12:39 PM, Cody Garver wrote:
>
>> Since the launchpad link for the
Okay, I think you're right. The dock's the correct place to start. How do you
feel about losing explicit minimize though? Do you guys think you can live
without it?
On Fri, Sep 21, 2012 at 2:27 AM, Sergey Shnatsel Davidoff
wrote:
2012/9/21 Nishant Agrwal
About applications that want to hide o
2012/9/21 Nishant Agrwal
> About applications that want to hide on close, don't they use other
> mechanisms like for example, a music player would hide to the Sound Menu?
>
I'll answer with a quote:
> In Ubuntu, many programs — Rhythmbox, Banshee, VLC, Pino, and Pidgin, to
> name just five — pu
My main reason for wanting this is to have a way to completely disable the
possibility of minimize, even by clicking on the dock. It will encourage
the user to use only workspaces for managing their windows.
For example, if I am done with a browser window for the time being, but I
want to keep it
Hello,
i'm trying to build power plug
https://code.launchpad.net/~elementary-os/pantheon-plugs/power-plug but i
get an error
chris@chris-Aspire-5732Z:~/Projects/power-plug/build$ make
Linking C executable power
CMakeFiles/power.dir/src/power.c.o: In function `main':
power.c:(.text+0x2dc3): undefi
Blurring the lines between minimize and close is a good vision that I'd
expect it to face challenges in real life for Luna. While the user
experience with elementary apps should be great, the reality is that the
Luna experience may not be that smooth for many users that depend on more
than just ele
I knew I forgot something, Files is there now too. That brings the total to
25 bugs.
On Thu, Sep 20, 2012 at 12:39 PM, Cody Garver wrote:
> Since the launchpad link for the project-wide luna-beta1 milestone has
> been down for a few days, I attempted to recreate it in a Google Doc.
>
>
> https:/
Since the launchpad link for the project-wide luna-beta1 milestone has been
down for a few days, I attempted to recreate it in a Google Doc.
https://docs.google.com/document/d/1JwPkslcEW9Ocync8f7WTn021GWeVEcHw6ZoFEtJNsdw/edit
If I missed anything, let me know. If you can't or don't want to view a
Sergey: +1
I think it's currently a bit confusing that
A. There is no minimize button
B. Clicking on the app in Plank minimizes
C. There is no indication that the app is running but minimized
So I think there should be no one-click way to minimize for the user. If a user
is desperately missing t
Cassidy,
Plank doesn't actually support hiding the indicators. What I meant is if
elementary decides to hide them then there should be a way to unhide
them if needed. Which means the shell-plug would have to provide such an
option (toggle between a reasonable indicator size and 0)
Am 2012-09-20 1
Until Luna is released, we will stick with GTK+ <= 3.4.x. Those apps
require GTK+ 3.5 (soon 3.6) to build, so I don't think they can be
integrated.
I think we should just fix our own plugs even if that takes longer.
On Thu, Sep 20, 2012 at 9:09 AM, Eduard Gotwig wrote:
> Hey, I suggest to use th
Rico,
Functionally that's the same, sure. But I think the idea is that it should
be a setting instead of a theming hack. Users should be able to say, "I
want to display running indicators" and flip a switch to do so.
On Sep 20, 2012 10:44 AM, "Rico Tzschichholz" wrote:
> Setting the size to 0 is
Setting the size to 0 is fairly the same as having them disabled. So I
don't really see the need in such an extra key, although adding one is
easy. If you insist please file an elementary-tagged bug.
Rico
Am 20.09.2012 01:49, schrieb Daniel Foré:
> Well the idea is that our default apps already m
Just to add something, indicators are also useful to show that an app has
requested your attention while you were away (for example, if you were
pinged on irc), so I'd say the red one should remain. About "normal" ones I
agree with shnatsel, let's keep them till we can provide a real no-minimize
en
2012/9/20 Nishant Agrwal
> What do you guys think of this:
> https://blueprints.launchpad.net/gala/+spec/option-to-disable-minimize
>
I can't see the point of that personally. Could you provide an example use
case in which disabling minimize on the WM side is better than leaving
things as they a
Generic names may lack pizzazz, but they are good at providing quick
descriptions of their functionality to new users. Also, generic names are
usually very simple/clean (read: minimalist). Basically they're highly
functional.
On Sep 19, 2012 11:25 PM, "Brendan" wrote:
> I think too many distros u
Hey, I suggest to use the printers panel in switchboard from GNOME 3.6.
It does integrate into the main window, and does not start an extra window:
https://live.gnome.org/Design/SystemSettings/Printers
Checkout the "mockups". I can't make a screenshot right now, I'm sry, but
there is not an extra
+1 on this and +1 on de-branded names on apps.
On September 19, 2012 at 8:00 PM Sam Tate wrote:
> In the long run (L+1 or even L+2), I want there to be no difference between
> an open and closed app
--
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-
31 matches
Mail list logo
