Re: [Elementary-dev-community] Luna +1's Name and Some Other Stuff

2013-08-16 Thread Avi Romanoff 
As I've said before, +1 for Isis :)

I can just hear the multitudes saying "WHAT??? BUT I THOUGHT THE NAMING
SCHEME WAS BASED ON PLANTS AND SPACE AND STUFF!"

It will be good to set the record straight ;)


On Fri, Aug 16, 2013 at 4:37 PM, Allen Lowe  wrote:

> Isis sounds great to me!
>
>
> On Fri, Aug 16, 2013 at 1:50 PM, A. "Xylon" V. wrote:
>
>> Just to clarify on my last mail, Iris is the Greek Goddess of the
>> Rainbow. And, well, elementary is colourful :)
>>  On Aug 16, 2013 8:45 PM, "A. "Xylon" V."  wrote:
>>
>>> I don't like isis. What about Iris?
>>> On Aug 16, 2013 8:33 PM, "Albert Abril"  wrote:
>>>
 Hi all,

 I'm new at the maillist,
 but just wanna say that I like a lot the name of Isis.

 Bests,
 Albert.


 On 16 August 2013 21:27, Cassidy James wrote:

> I like the sound of Isis. :)
>
> Regards,
> Cassidy James
>
> --
> Sent from *elementary OS* .
>
>
> On Fri, Aug 16, 2013 at 2:16 PM, Mario Guerriero 
> wrote:
>
>> Isis is fine for me.
>> —
>> Sent from Mailbox  for iPhone
>>
>>
>> On Fri, Aug 16, 2013 at 9:15 PM, alienus  wrote:
>>
>>> Yes, the codename is great, and thanks for the other news.
>>> All seems very good.
>>>
>>> Keep up the good work.
>>>
>>> Best regards.
>>>
>>> --alienus
>>>
>>> Le 16/08/2013 21:13, Alfredo Hernández a écrit :
>>> > +1 for Isis, it feels completely right for elementaryOS.
>>> >
>>> > On 16 Aug 2013 21:09, "Daniel Foré" >> > > wrote:
>>> >
>>> > Hey dudes (and hopefully a few dudettes these days),
>>> >
>>> > First of all, congratulations to all of you on 100k+ downloads in
>>> > the first week. That is freaking killer. We're getting rave reviews
>>> > and (despite bug #1 being closed) we keep hearing from tons of
>>> > people that are first-time Linux users coming from Windows and Mac
>>> > OS. If you haven't been in contact with this positive energy yet, I
>>> > encourage you to hit up youtube for an ego boost. Now down to
>>> business!
>>> >
>>> > I'm writing to announce the codename of the next elementary
>>> release:
>>> > "Wanking Wallaby"
>>> >
>>> > Jk. What is this, Ubuntu?
>>> >
>>> > I'm leaning strongly towards "Isis" for this one. It's short (2
>>> > syllables), should be generally pretty easy to pronounce, etc. Isis
>>> > is the egyptian mother god of the throne, "friend of slaves,
>>> > sinners, artisans, and the downtrodden". You can read up more about
>>> > her here: http://en.wikipedia.org/wiki/Isis
>>> >
>>> > Munchor says I should go full Hitler and not allow any arguments,
>>> > but if you think the name totally sucks you can definitely say
>>> that.
>>> > If not, let's go with it! (And even if so, we'll probably still go
>>> > with it!)
>>> >
>>> > Also, I think in general most of us think it would be the best idea
>>> > to release Isis (see, I'm already going with it) as closely as
>>> > possible to Ubuntu 14.04. We have a lot to prove about our ability
>>> > to provide updates in a timely manner and we're getting some
>>> > negative feedback from developers/nerds about our 12.04 base. So
>>> > let's address that and make sure that elementary is the best open
>>> > platform for both users and developers (and I guess nerds too).
>>> >
>>> > Cody is currently working on updating Congrego to spit out some
>>> > super bleeding edge Saucy-based builds. If any of you are already
>>> on
>>> > Saucy, you know how broken Pantheon currently is. Indicators and
>>> > Plugs are huge problems that we need to address. We're considering
>>> > moving both of these into lib peas plugins for Wingpanel and
>>> > Switchboard (respectively). Any feedback on that plan is very
>>> welcome.
>>> >
>>> > In general, the first priority for Isis is going to be updating all
>>> > of our apps to compile/run with the latest libraries. You should
>>> > know that Midori with the latest webkitGTK is amazing. I'm working
>>> > on porting eGtk and it's going pretty swell. You should also know
>>> > that all the fancy libaccounts stuff is now available for someone
>>> to
>>> > start playing with so we can get sweet online integration. I
>>> believe
>>> > that Clutter with the touch-related bits is also available so that
>>> > is also very exciting for those of use that have a multi-touch
>>> > trackpad available.
>>> >
>>> > Anyways, let's get rolling on this cycle. We have 8 months to
>>> become
>>> > even more awesome.
>>> >
>>> > For the greater glorification of our Holy Mother Isis,
>>> >
>>> > Daniel Foré
>>> >
>>> > elementaryos.org

[Elementary-dev-community] Fwd: RFC: gesture management model

2013-08-10 Thread Avi Romanoff 
Forwarding this into the dev community. I haven't read through this (nor am
I in a position to contribute code to elementary for the next several
months), but this seems to be something we should definitely look into for
the L+1 cycle.

-- Forwarded message --
From: Carlos Garnacho 
Date: Sat, Aug 10, 2013 at 6:18 PM
Subject: RFC: gesture management model
To: gtk-devel-list 


Hey,

On the gestures GTK+ branch there is a collection of event controllers
that interpret events in order to trigger actions. This branch never
really got into how do gestures get handled throughout a hierarchy, as
Matthias pointed out on preliminary review.

So I've been thinking in how gesture management happen as a toolkit
feature, and I'm now looking into putting this into practice, but would
be great to get comments soon in the loop. It is worth mentioning that
the gestures branch already goes in the proposed direction, even though
it currently focuses on plain event handling currently.

In the blurb below I talk much about "touch sequences", but controllers
could pretty much manage any kind of event, so this pretty much applies
to any user interaction.

Event Controllers
-

The gestures branch defines basic event handling, in order to have these
controllers work throughout a widget hierarchy, I've tried to define
further how should these behave:

  * These handle GdkEvents and GtkWidget::grab-notify.
  * Each subclass tries to recognize a concrete action.
  * The number of touch sequences a controller handles doesn't
change
  * A touch sequence can be declined at any point, for external and
internal reasons.
  * Controllers must acknowledge/decline a touch sequence ASAP,
usually based on timeouts or thresholds.
  * Controllers keep track of touch sequences during all their
lifetime, regardless of the point above. This acts as an
"implicit grab" on a gesture, making any later touch sequence
ineffective till the/a monitored one disappears.

Note that this pursue for simplicity in event handling means that
multiple controllers might be interested in the same events, even within
the same widget. With that defined behavior, a basic set of gestures
could look like:

  * Tap/Click: For simple clicks.
  * Long press: For long, mostly stationary presses.
  * Drag: Handles drags, reports dx/dy from initial coordinates.
  * Swipe: Reports direction/velocity when a sequence finishes.
  * Zoom/Pinch: Handles 2 touch sequences, reports distance changes
  * Rotate: Handles 2 touch sequences, reports angle changes

If we go for this model where separate touch sequences can be accepted
or declined at different controllers, and controllers report early
enough whether the handled action is being triggered, the possible
overall states a controller goes through would be:

  Idle > Capturing > Idle
  Idle > Capturing > Declined > Idle
  Idle > [ Capturing > Acknowledged ]+ > Idle

Handling through the hierarchy
--

By the way event controllers make use of events, I think it is best for
those to take events from the GtkWidget::captured-event handler, so
events are effectively handled from the topmost to the deepmost widget,
and the implicit grab ensures the widget stack receiving events from a
touch sequence is static (until active grabs come at least, but all
sequences should be declined in that case anyway).

Independently to the way events are delivered, a same event could be fed
on multiple event controllers throughout the implicit grab widget stack,
and any of those can enter the "Acknowledged" state anytime.

However, what "Acknowledged" on a controller means is widget dependent,
as is also how multiple controllers work together within the same
widget. So any model to reclaim users actions for a single purpose must
happen at the widget level.

On such model, there should be at least a way to make a widget ACK on a
touch sequence, and a signal to have other widgets in the implicit grab
widget stack decline that same sequence. This way, a widget in the stack
may claim control while the others back out. So essentially:

  void (* ownership_claimed) (GtkWidget *widget,
  GdkEvent  *event);
  ...

  void gtk_widget_claim_ownership (GtkWidget *widget,
   GdkEvent  *event);


>From the usecases below, it is hard to find a fully comprehensive
high-level behavior, specially as for how do intra-widget controllers
get to cooperate together, I think a good default for the most common
cases would be:

  * A widget can be set 0..n controllers (Usually 1 or 2 most
hopefully)
  * All controllers get fed all events by default
  * When a gesture enters in Acknowledged state, all touch sequences
handled there are claimed for the widget.
  * A touch sequence being claimed elsewhere makes all other widgets
decli

Re: [Elementary-dev-community] Just look at all the progress we made!

2013-08-10 Thread Avi Romanoff 
+999 to that, Shnatsel. And thank you to for your hard work... Luna
seriously would not have been possible without you :)

I haven't checked the new sources yet, but we were the top post on Hacker
News for most of the night:



On Sat, Aug 10, 2013 at 10:51 PM, Sergey "Shnatsel" Davidoff <
ser...@elementaryos.org> wrote:

> Also I want to congratulate everybody who every contributed, but it's
> almost 7AM and I haven't slept today at all, so I can't generate anything
> more sophisticated than THANK YOU GUYS YOU ROCK!!
>
> Also, somebody please make a list of news coverage and reviews we get! I'd
> really want to read it for one, even if in retrospect.
>
> --
> Sergey "Shnatsel" Davidoff
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Just look at all the progress we made!

2013-08-10 Thread Avi Romanoff 
*derp, accidentally hit the send button:
https://news.ycombinator.com/item?id=6193148

Also, #elementaryOS is currently the #4 trending topic globally on all of
Google+!


On Sun, Aug 11, 2013 at 2:38 AM, Avi Romanoff  wrote:

> +999 to that, Shnatsel. And thank you to for your hard work... Luna
> seriously would not have been possible without you :)
>
> I haven't checked the new sources yet, but we were the top post on Hacker
> News for most of the night:
>
>
>
> On Sat, Aug 10, 2013 at 10:51 PM, Sergey "Shnatsel" Davidoff <
> ser...@elementaryos.org> wrote:
>
>> Also I want to congratulate everybody who every contributed, but it's
>> almost 7AM and I haven't slept today at all, so I can't generate anything
>> more sophisticated than THANK YOU GUYS YOU ROCK!!
>>
>> Also, somebody please make a list of news coverage and reviews we get!
>> I'd really want to read it for one, even if in retrospect.
>>
>> --
>> Sergey "Shnatsel" Davidoff
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] pantheon-wallpaper won't make it

2012-04-04 Thread Avi Romanoff 
Big +1 from me.

It's basically an abandoned project (and has been for months), and some
core integration features are still missing, to say nothing of the fact
that it's riddled with serious bugs.

Avi

On Thu, Mar 29, 2012 at 11:37 PM, Cassidy James  wrote:

> At first I was pretty against this... ("All that work down the drain!")
> But it seems the best option for Luna. Its original purpose is no longer
> relevant, and it's not needed for Luna.
>
> As far as post-Luna is concerned, I'm definitely interested in using
> Pantheon Wallpaper and other customer Pantheon solutions to supplant the
> GNOME counterparts if they're genuinely better. However it's also important
> to not let pride get in our way; GNOME has been doing this longer than us
> and is doing some awesome things with GNOME 3 compared to the legacy GNOME
> 2 that we were used to when we started with Pantheon.
>
> Regards,
> Cassidy James
> On Mar 29, 2012 10:13 PM, "Victor Eduardo" 
> wrote:
>
>> I agree. *pantheon-wallpaper* is still not ready for Luna. All the
>> planned cool features supporting the effort are yet to be implemented and
>> since GNOME doesn't depend on Nautilus to render the wallpaper anymore, it
>> would be a clever move to just use that. Pantheon is just a shell, while
>> GNOME is a desktop environment and we depend on it anyway.* *Plus eOS
>> will be super lightweight without it.*
>> *
>> I don't know if dropping the project is a good idea, but we definitely
>> don't want pantheon-wallpaper to be shipped in Luna in its current state.
>>
>> Also, the most popular applications (Shotwell, etc.) are designed for use
>> in the GNOME platform, and we want the OS to be compatible with the current
>> spec. The new desktop-agnostic implementation should be introduced after
>> Luna.
>>
>> Regards.
>>
>> On Thu, Mar 29, 2012 at 8:04 AM, Сергей  wrote:
>>
>>> Hello everybody,
>>>
>>> it's hard to admit it, but pantheon-wallpaper probably won't make it
>>> for Luna. It has dreadful bugs like
>>> https://bugs.launchpad.net/pantheon-wallpaper/+bug/814948 or
>>> https://bugs.launchpad.net/pantheon-wallpaper/+bug/886633 and no
>>> active maintainer.
>>>
>>> Moreover, I think it's no longer relevant. It was started back when
>>> Nautilus was drawing wallpaper. Nowadays GNOME wallpaper is drawn by
>>> gnome-settings-daemon, so the advantage of being standalone is no
>>> longer relevant. Pantheon-wallpaper uses Cairo for rendering and
>>> therefore its transitions are smoother, but I've compared them on a
>>> laptop back from 2005 and I can't say pantheon-wallpaper is *much*
>>> smoother. In addition, GNOME implementation supports interfaces about
>>> which we haven't even dreamed about yet, e.g. libvte
>>> semi-transparency, Ubuntu lock screen, etc, and its way of storing
>>> configs is already widely supported.
>>>
>>> Smooth transitions are a job of GPU drivers. Client-side workarounds
>>> for that are not a good idea. GDK pixbuf which is [probably] used by
>>> gnome-settings-daemon is more likely to get performance improvements
>>> from GPU drivers than Cairo. Latest Intel drivers boost its
>>> performance many times compared to previous versions, while Cairo
>>> performance is largely unchanged.
>>>
>>> Maintaining a custom solution for the sake of improvement
>>> opportunities doesn't make much sense either. Most features like
>>> https://blueprints.launchpad.net/pantheon-wallpaper/+spec/focus-blur
>>> should be implemented as standalone daemons telling the wallpaper what
>>> to do, not inside wallpaper service to bloat it with potentially
>>> unused features.
>>> And it's very unlikely that we'll drop gnome-settings-daemon in the
>>> foreseeable future, so the original problem which led to creation of
>>> pantheon-wallpaper is extremely unlikely to reappear.
>>>
>>> Given all of the above, I propose dropping pantheon-wallpaper
>>> completely. It's not worth the effort.
>>>
>>> --
>>> Sergey "Shnatsel" Davidoff
>>>
>>> --
>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>> Post to : elementary-dev-community@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Automatic Branch Merging

2012-02-08 Thread Avi Romanoff 
YAY!!!

5000 Internet points to you, good sir.

On Sun, Feb 5, 2012 at 10:19 AM, Cassidy James  wrote:

> Dude, this is awesome, Fabian. You rock! :D
> On Feb 5, 2012 8:14 AM, "Fabian Thoma"  wrote:
>
>> Hey guys,
>>
>> Yesterday I finally got tarmac to work, so our loved RabbitBot will
>> now merge all of the approved branches in Launchpad that have a commit
>> message set. So no more manual merging & pushing, all done every 15
>> minutes automatically.
>>
>> I got all Pantheon branches set up and will add the main branches of
>> other projects in the next few hours, if you want stuff merged,
>> RabbitBot(~rabbitbot-a) needs to have access to the bzr branches and
>> Launchpad Project management, it currently is part of ~elementary-core
>> so the most app branches should be accessible by it, if not, add him
>> to your team.
>>
>> If you need automatic merging for special branches send a email to me ;)
>>
>> --
>> Fabian Thoma | Council Member
>> elementary OS
>> fab...@elementaryos.org / elementaryos.org
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Dropping Granite.Widgets.HintedEntry

2012-01-17 Thread Avi Romanoff 
Agreed. I'll make those changes (namely just re-instating
Granite.Widgets.HintedEntry and adding a deprecation warning) to my branch
when I've got some time.

On Tue, Jan 17, 2012 at 1:39 PM, Allen Lowe  wrote:

> +1 to Lucas
>
> Allen Lowe
>
> On Tue, Jan 17, 2012 at 11:09 AM, Lucas Baudin  wrote:
> > It would be better to do the transition in two steps: first, you change
> > the hintedentry to use the normal entry (just a bridge beetween the
> > properties), and add a warning (critical), and only then, you remove it.
> >
> >
> > Le lundi 16 janvier 2012 à 19:22 -0700, Allen Lowe a écrit :
> >> We'll need to rewrite search bar to be based on the standard entry.
> >>
> >> On Jan 15, 2012 3:06 PM, "Avi Romanoff"  wrote:
> >> I've committed that change to my
> >> branch:
> http://bazaar.launchpad.net/~aroman/granite/entries-redux/revision/159
> >>
> >>
> >> Avi
> >>
> >> On Sun, Jan 15, 2012 at 4:31 PM, Daniel Foré
> >>  wrote:
> >> Hey Avi,
> >>
> >>
> >> For the primary icon we should probably be using
> >>         "edit-find-symbolic" with the fallback.
> >>
> >> Best Regards,
> >> Daniel Foré
> >>
> >>
> >> www.elementaryos.org
> >>
> >> On Jan 15, 2012, at 12:37 PM, Avi Romanoff
> >>  wrote:
> >>
> >>
> >>
> >> > Hi all,
> >> >
> >> >
> >> > After some discussion in IRC yesterday (and
> >> > previously) there was a consensus that we should use
> >> > GtkEntry's placeholder-text property that exists in
> >> > 3.0.
> >> > Granite.Widgets.HintedEntry did basically what
> >> > placeholder-text does, with the addition of italics,
> >> > which Dan agreed aren't really helpful/necessary.
> >> >
> >> >
> >> > Therefore it makes sense to drop HintedEntry
> >> > entirely from Granite. However,
> >> > Granite.Widgets.SearchBar -- the only child of
> >> > HintedEntry -- should be retained.
> >> > This is because it adds a number of useful features
> >> > the the standard entry:
> >> >
> >> >
> >> > - 'gtk-find' as primary icon
> >> > - 'edit-clear-symbolic' as secondary icon (with
> >> > fallback)
> >> > - intelligently showing/hiding the secondary icon
> >> > - click the secondary icon to clear the entry
> >> > - new signal and configurable delay when the user
> >> > has stopped typing -- useful for a search callback
> >> >
> >> >
> >> > So, it would make sense to keep SearchBar around and
> >> > simply have it inherit from HintedEntry, and keep
> >> > the API exactly the same.
> >> >
> >> >
> >> > I have done this in a feature-branch
> >> > here:
> https://code.launchpad.net/~aroman/granite/entries-redux
> >> >
> >> >
> >> > The only really significant thing here is that we're
> >> > dropping a widget entirely. If there is support for
> >> > it, I could add the HintedEntry back in and simply
> >> > use the placeholder-text property, and give it a
> >> > deprecation warning.
> >> >
> >> >
> >> > There are no public API changes to SearchBar (or
> >> > HintedEntry if the above is implemented)
> >> >
> >> >
> >> > Oh, and fwiw here's what it would look like to
> >>

Re: [Elementary-dev-community] Dropping Granite.Widgets.HintedEntry

2012-01-15 Thread Avi Romanoff 
I've committed that change to my branch:
http://bazaar.launchpad.net/~aroman/granite/entries-redux/revision/159

Avi

On Sun, Jan 15, 2012 at 4:31 PM, Daniel Foré wrote:

> Hey Avi,
>
> For the primary icon we should probably be using "edit-find-symbolic" with
> the fallback.
>
> Best Regards,
> Daniel Foré
>
> www.elementaryos.org
>
> On Jan 15, 2012, at 12:37 PM, Avi Romanoff  wrote:
>
> Hi all,
>
> After some discussion in IRC yesterday (and previously) there was a
> consensus that we should use GtkEntry's placeholder-text property that
> exists in 3.0.
> Granite.Widgets.HintedEntry did basically what placeholder-text does, with
> the addition of italics, which Dan agreed aren't really helpful/necessary.
>
> Therefore it makes sense to drop HintedEntry entirely from Granite.
> However, Granite.Widgets.SearchBar -- the only child of HintedEntry --
> should be retained.
> This is because it adds a number of useful features the the standard entry:
>
> - 'gtk-find' as primary icon
> - 'edit-clear-symbolic' as secondary icon (with fallback)
> - intelligently showing/hiding the secondary icon
> - click the secondary icon to clear the entry
> - new signal and configurable delay when the user has stopped typing --
> useful for a search callback
>
> So, it would make sense to keep SearchBar around and simply have it
> inherit from HintedEntry, and keep the API exactly the same.
>
> I have done this in a feature-branch here:
> https://code.launchpad.net/~aroman/granite/entries-redux
>
> The only really significant thing here is that we're dropping a widget
> entirely. If there is support for it, I could add the HintedEntry back in
> and simply use the placeholder-text property, and give it a deprecation
> warning.
>
> There are no public API changes to SearchBar (or HintedEntry if the above
> is implemented)
>
> Oh, and fwiw here's what it would look like to replacate what HintedEntry
> does with Gtk.Entry in your code:
>
> search_box = new Gtk.Entry ();
> search_box.placeholder_text = _("Search Plugs");
>
> So just one more line.
>
> (Also note the wording -- the "Labeling" section has been added to the
> HIG. Please look it over and make any changes that are appropriate:
> http://elementaryos.org/docs/human-interface-guidelines/ui-toolkit-elements/search-fields
> )
>
> Thanks,
> Avi
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

[Elementary-dev-community] Dropping Granite.Widgets.HintedEntry

2012-01-15 Thread Avi Romanoff 
Hi all,

After some discussion in IRC yesterday (and previously) there was a
consensus that we should use GtkEntry's placeholder-text property that
exists in 3.0.
Granite.Widgets.HintedEntry did basically what placeholder-text does, with
the addition of italics, which Dan agreed aren't really helpful/necessary.

Therefore it makes sense to drop HintedEntry entirely from Granite.
However, Granite.Widgets.SearchBar -- the only child of HintedEntry --
should be retained.
This is because it adds a number of useful features the the standard entry:

- 'gtk-find' as primary icon
- 'edit-clear-symbolic' as secondary icon (with fallback)
- intelligently showing/hiding the secondary icon
- click the secondary icon to clear the entry
- new signal and configurable delay when the user has stopped typing --
useful for a search callback

So, it would make sense to keep SearchBar around and simply have it inherit
from HintedEntry, and keep the API exactly the same.

I have done this in a feature-branch here:
https://code.launchpad.net/~aroman/granite/entries-redux

The only really significant thing here is that we're dropping a widget
entirely. If there is support for it, I could add the HintedEntry back in
and simply use the placeholder-text property, and give it a deprecation
warning.

There are no public API changes to SearchBar (or HintedEntry if the above
is implemented)

Oh, and fwiw here's what it would look like to replacate what HintedEntry
does with Gtk.Entry in your code:

search_box = new Gtk.Entry ();
search_box.placeholder_text = _("Search Plugs");

So just one more line.

(Also note the wording -- the "Labeling" section has been added to the HIG.
Please look it over and make any changes that are appropriate:
http://elementaryos.org/docs/human-interface-guidelines/ui-toolkit-elements/search-fields
)

Thanks,
Avi
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Functions

2012-01-03 Thread Avi Romanoff 
I agree with Christian's comments -- we're writing in Vala, if anything, we
should be strongly encouraging the existing styles.

Also, have we considered the existing style documentation we drafted a
while ago? (I think it might still be internal for whatever reason, so I'll
post it here:

Coding Style

   - Indentation is done using 4 spaces. *not tabs.*
   - Between 80 to 120 characters per line
   - Cuddled else
   - Hanging curly brackets
   - snake_case for methods and variables
   - Class names are PascalCase
   - SCREAMING_CAPS for enumerations and constants
   - No hungarian notation
   - C-style multi-line comments
   - Spaces between expression or function name and opening brackets
   - Explicit namespaces, no using


I also drafted some similar guidelines about function styles, but this was
before the contributor meetings were implemented so it was basically
impossible to come to a rational/reasonable conclusion within the council
(since the council has basically no reason or motivation to make sweeping
style-guides -- that obviously should happen bottom-up from the developers
themselves).

How about we merge/link the existing drafts and bring this up at the next
contributor meeting?

Avi

On Mon, Jan 2, 2012 at 2:56 PM, Scott Ringwelski  wrote:

> I prefer something like this:
>
> public int my_function(string var) {
> int rv = 0; // var declarations
>
> // code
>
> return rv; // return has empty line before it.
> }
>
> to call it:
> var result = my_function("hi");
>
> Having an empty line after the function declaration looks really odd to
> me. I also prefer not space between the function name and params.
>
> What about function comments? I think function comments aren't really
> necessary, except for the especially important ones or common ly used ones.
>
> On Mon, Jan 2, 2012 at 11:19 AM, David Gomes wrote:
>
>> Ideally, for me, I'd love:
>>
>> public int my_function ()
>> {
>>   //Code
>> }
>>
>> It's the best way because the parentheses are aligned, so I can see where
>> the function starts and where it ends.
>>
>> However, I know most of you don't like it, we'll have to choose between
>> these: (notice the empty line difference)
>>
>> void my_function () {
>>
>>   //Code
>> }
>>
>> void my_function () {
>>   //Code
>> }
>>
>> I prefer first because it makes code more organized when there are lots
>> of lines. Besides, we're already doing it in most of our code.
>>
>> http://goo.gl/l7a88 I'm also working on this. I decided I would do this
>> because I'm a coding style freak. Code needs to be perfect and consistent
>> along all of our applications. In fact, I can volunteer to fix all the
>> dirty code we have (it's boring, but I don't care, I love doing it) in all
>> our apps, but only after we have a coding style defined.
>>
>> Which one do you prefer? Thanks, discuss, and don't forget to "Reply to
>> all".
>>
>>
>> --
>> David Gomes
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Scott Ringwelski
> 231-492-5380
> sgrin...@mtu.edu
>
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Reddit and website suggestions

2012-01-01 Thread Avi Romanoff 
Hey Jaap,

Thanks for showing us this! It's pretty cool that we got such an active,
albeit occasionally negative thread going.

I do thing most of the legitimate criticism (i.e well-meaning) is valid
though -- we don't really do much explaining of *what* elementary is, why
it's an "OS", or frankly, what it does.

I do believe that this will change with the website "2.0" hopefully in
time/before Luna. Plus, Luna is so many worlds (pun intended) away from
Jupiter that it should be much clearer what it is that we as a project are
capable of.

Oh and mad props for keeping that thread sane and representing us so well,
Jaap!

Avi

On Wed, Dec 28, 2011 at 12:19 PM, Jaap Broekhuizen wrote:

> Hey guys,
>
> I hope you all are having great holidays!
>
> A few days ago there was a topic about us on reddit and it has some nice
> (and some less nice) comments, and suggestions:
> http://www.reddit.com/r/linux/comments/nq2gn/poor_elementary_os_developers/
>
> I think especially the following sub-thread is very important, it has
> some good suggestions (mainly about the website):
>
> http://www.reddit.com/r/linux/comments/nq2gn/poor_elementary_os_developers/c3b3km8
>
> The main thing that is said is that we are lacking (quote) "[a] section
> to explain in simple terms what it is and what their philosophy is". I
> think it would be wise if we took the suggestions and really incorporate
> them in our website.
>
> I hope this is the right place to post this btw...
>
> Jaap
> --
> This message was sent from Launchpad by
> Jaap Broekhuizen (https://launchpad.net/~jaapz-b)
> using the "Contact this team" link on the Elementary Developer Community
> team page (https://launchpad.net/~elementary-dev-community).
> For more information see
> https://help.launchpad.net/YourAccount/ContactingPeople
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Problem with GSettings and Wingpanel

2011-12-21 Thread Avi Romanoff 
It looks like your gsettings schemas got a bit out of whack. I'd try
re-installing the relevant keys by re-installing the relevant
applications/packages.

Unless I'm completely wrong and there's something more significant
happening here, but maybe someone else will be able to point it out.

Avi

On Wed, Dec 21, 2011 at 2:29 PM, David Gomes wrote:

> The other day, aroman helped me installing his branch of wingpanel, with
> fixed shadow. However, we had to tweak some stuff in order to make it work.
> When compiling any elementary app now (e. g.: Pantheon Terminal), I get
> this:
>
> -- Install configuration: ""
> -- Up-to-date:
> /usr/share/glib-2.0/schemas/org.elementary.pantheon-terminal.gschema.xml
> -- Compiling GSettings schemas
> No such key `picture-filename' in schema `org.gnome.desktop.background' as
> specified in override file
> `/usr/share/glib-2.0/schemas/25_elementary-default-settings.gschema.override';
> ignoring override for this key.
> No such key `backlight-battery-reduce' in schema `org.gnome.power-manager'
> as specified in override file
> `/usr/share/glib-2.0/schemas/25_elementary-default-settings.gschema.override';
> ignoring override for this key.
> No such key `brightness-dim-battery' in schema `org.gnome.power-manager'
> as specified in override file
> `/usr/share/glib-2.0/schemas/25_elementary-default-settings.gschema.override';
> ignoring override for this key.
> error parsing key `exec' in schema
> `org.gnome.desktop.default-applications.terminal' as specified in override
> file
> `/usr/share/glib-2.0/schemas/25_elementary-default-settings.gschema.override':
> 0-8:unknown keyword.  Ignoring override for this key.
> -- Up-to-date: /usr/bin/pantheon-terminal
> -- Up-to-date: /usr/share/applications/pantheon-terminal.desktop
> david@davidbuntu:~/src/pantheon-terminal/build$
>
> I need this fixed as soon as possible because if this remains I can't
> develop. What do you suggest? Thanks.
>
>
>
> --
> David Gomes
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

[Elementary-dev-community] Fwd: GTK+ 3.3.6

2011-12-20 Thread Avi Romanoff 
I dunno if you guys are subscribed to the gnome announce/gtk-devel mailing
lists, but I thought this release seemed relevant.

That is, the TreeView refactor (read: speed) has landed in trunk, wayland
support, and some interesting GApplication and theming changes.

Avi

-- Forwarded message --
From: Matthias Clasen 
Date: Mon, Dec 19, 2011 at 7:16 PM
Subject: GTK+ 3.3.6
To: gnome-announce-l...@gnome.org, gtk-devel-l...@gnome.org,
gtk-app-devel-l...@gnome.org, gtk-l...@gnome.org


GTK+ 3.3.6 is now available for download at:

 ftp://ftp.gtk.org/pub/gtk/3.3/
 http://download.gnome.org/sources/gtk+/3.3/

ae614b054fa313ae11400eb3446c5b83b41366885946b9375142536ee4944c16  gtk
+-3.3.6.tar.xz

Another 3.3 development snapshot.



GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable for
projects ranging from small one-off tools to complete application
suites.

GTK+ has been designed from the ground up to support a range of
languages, not only C/C++. Using GTK+ from languages such as Perl and
Python (especially in combination with the Glade GUI builder) provides
an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the
licensing terms for GTK+, the GNU LGPL, allow it to be used by all
developers, including those developing proprietary software, without
any license fees or royalties.


Overview of Changes in GTK+ 3.3.6
=

* GtkApplication has grown support for exporting application
 menus and menubars on the bus, as a GMenuModel. The
 new GtkApplicationWindow toplevel automatically
 displays these menu models when needed. These APIs
 are still EXPERIMENTAL and are likely to change
 before 3.4.

* GtkSpinButtons have received a long-overdue face-lift
 to make them easier to use with both mouse and touch.

* GtkScale has gained a has-origin property to request
 filled-in drawing of the trough.

* GtkWindow can now request that the window manager hide
 the titlebar when the window is maximized.

* The GtkTreeView accessibility support and the core
 treeview code have been extensively refactored;
 performance should be much improved. But watch out
 for regressions.

* The GtkFileChooser entry completion code has been
 extensively refactored; it now uses GtkEntryCompletion

* Excessive dependencies have been culled from Requires:
 lines in pc files. Dependent modules may have to declare
 dependencies that they were getting 'for free' in the past.

* Theming improvements:
 - The background-clip and background-origin CSS properties
  have been implemented

* Win32 improvements:
 - Theming of column headers, radio buttons and menuitems,
  notebook tabs, etc has been fixed
 - Menus, tooltips, and other popups show above the task bar

* Wayland:
 - The Wayland backend has been updated to the current Wayland API

* Bugs fixed:
 603823 Print to File suggests ".ps" as filename...
 640317 gtk_draw_insertion_cursor should be moved to gtk_render
 646461 Leak in gtkfilechooserbutton.c: model_free_row_data
 650943 Clicking resize grip causes strange mouse grabbing beh...
 661428 Allow themes to know when a toplevel window appears un...
 662814 Request for way to tell gtk_recent_manager_add_item_qu...
 664137 Crash in Audacious audio player when browsing the add ...
 664456 segfault on arrow keypress in empty GtkIconView
 664467 prop-editor is broken for GdkColor properties
 664469 color button doesn't notify "color" and "alpha" when c...
 664537 GtkCssProvider: don't segfault when CSS file is not found
 664640 CUPS authentication does not work
 665140 Draw the scale split
 665326 FTBFS: missing Xi/Pango/Fc for gtk-query-immodules-3.0
 665616 Add hide-titlebar-when-maximized setting
 665741 Crashes in treeview when pressing End key.
 665999 Introspection wrong for GDK_INPUT_ONLY vs GDK_INPUT_OUTPUT
 666242 Separators in menuitem are not vertically aligned
 641999 Consider adding a workarea API
 657578 Toggling the state of a GtkCheckButton causes accessible...
 659445 Accessible event.any_data is incorrect for text-removed...
 663573 Rework GtkFileChooserEntry
 666392 widget: Flip the sensitive flag even if the state doesn't...
 666552 Layered region is leaked in GdkWindow

* Updated translations
 Breton
 Kazakh
 Russian
 Slovak
 Spanish

Thanks to the contributors:
Benjamin Otte
Cosimo Cecchi
Federico Mena Quintero
Christian Persch
Alexander Larsson
Florian Müllner
Javier Jardón
Mike Gorse
Paolo Borelli
Stef Walter
Claudio Saavedra
Kristian Høgsberg
Rob Bradford
Rui Matos
Timothy Arceri
Ryan Lortie
Jan Rękorajski
Marek Kasik
Andrea Cimitan
Ignacio Casal Quinteiro
Carlos Garnacho
Colin Walters
William Hua
Xan Lopez

December 19, 2011
Matthias Clasen


___
gtk-devel-list mailing list
gtk-devel-l...@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
-- 
Mailing list: https://launchpad.net/~e

[Elementary-dev-community] Developer forum meetings

2011-11-28 Thread Avi Romanoff 
Hi all,

One of the things that was discussed at Saturday's council meeting was the
elementary developer forum.

There will be a Journal post about this soon no doubt, but it would be good
to get a consensus about a date and time that works best for everyone.

The Developer Forum would likely meet weekly, and will be open to all
elementary developers. (Basically if you have voice in #elementary-dev,
you're welcome to participate).

*Please reply with a day of the week & time that would work best for you.*
Expect meetings to take anywhere from 20 minutes to 2 hours.

Keep in mind that it cannot overlap with the council meeting, which is
Saturdays at 3:30PM EST (8:30PM UTC).

Thanks!
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] What it takes to be a dev

2011-11-19 Thread Avi Romanoff 
While I don't disagree with that, I think it's something we're trying to
move away from.

I could be wrong, but I think that for elementary to thrive as a platform
for third-party developers, we're going to automate packaging fully. (Maybe
not for libraries, but certainly for apps).

Granted, this is probably completely moot since none of that technology
exists. I guess I just wanted us to not get *too* carried away about
packaging (and this is probably in agreement with what Christian and Serge
are saying) and not spend a great deal of time if any discussing it in
documentation.

Just my $0.02.

On Sat, Nov 19, 2011 at 2:21 PM, Christian Dywan wrote:

> Am 19.11.2011 09:22, schrieb Сергей:
>
>  Regarding daily builds: they require existing Debian packaging, and I
>> don't think it's a good idea to make the developer package their app,
>> too.
>> Division of labor produces better results, and since I don't have a
>> monopoly for Debian packaging in elementary anymore (Mario Guerriero
>> and Cody Garver package stuff very well), packaging shouldn't be a
>> bottleneck.
>>
> I heavily second that. I've said it more than once. It is very rare for
> developers to package their own software. If a package is any good,
> packagers take care of it. Packagers have the benefit of more experience,
> routine and finding additional bugs. And it takes away development time.
>
>
> --
> Mailing list: 
> https://launchpad.net/~**elementary-dev-community
> Post to : 
> elementary-dev-community@**lists.launchpad.net
> Unsubscribe : 
> https://launchpad.net/~**elementary-dev-community
> More help   : 
> https://help.launchpad.net/**ListHelp
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] [Granite] PopOvers

2011-10-07 Thread Avi Romanoff 
Major props to Lucas and the others who are implementing popovers --
methinks it's going to be a great boon for elementary apps.

I definitely agree with Lucas that all of these versions should be published
and committed to as actively as possible -- don't worry about it being
official. I think we should have a formal code-review of them when they're
done and pick/combine the best one(s) as Max suggested.

Avi

On Fri, Oct 7, 2011 at 1:19 PM, Lucas Baudin  wrote:

>  Ah, that's cool, let me know if you have any problem :)
>
> (It's not only for you, Max did the same, but don't forget to CC the
> mailing list!)
>
> On 10/06/2011 10:40 PM, Mario Guerriero wrote:
>
> Lucas you are doing a great job. I started the implementation of PopOver
> also in Dexter
>
> http://elementaryositdev.files.wordpress.com/2011/10/screenshot-at-2011-10-06-143226.png
>
>
> 2011/10/6 Lucas Baudin 
>
>> Hi,
>>
>> I started implementing the PopOvers in granite. Here are some screenshots:
>> Midori: http://pix.toile-libre.org/upload/original/1317488418.png (needs
>> a patched midori, but it also needs the gtk3 patch which is not in git yet)
>> Ergo: 
>> http://pix.toile-libre.org/upload/original/1317927299.png(lp:~xapantu/ergo/popover)
>>
>> For technical details, it uses a composited window to draw the shadow
>> (yeah, it would be better if the window manager could handle this, but
>> unfortunately I don't know any wm which does) and subclass Gtk.Dialog.
>>
>> I would like to check that the current API is usable everywhere before
>> merging anything, so, if you could test in your apps if it works and/or send
>> me an application which would need a popover, it would be a good thing.
>>
>> The code is at lp:~elementary-pantheon/granite/popovers
>>
>> Feedback and comments welcomed :)
>>
>> Lucas
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to : elementary-dev-community@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Granite Logger

2011-08-14 Thread Avi Romanoff 
Hey,

In that case, why should logger.notification() exist when I should just be
able to use g_message()?

But actually, message(), logger.notification(), and debug() do *not* print
to terminal. I tested all of the logging convenience functions I could find
and threw this into my code:

var logger = new Granite.Services.Logger ();
logger.initialize(APP_TITLE);
logger.notification("logger.notify();");
warning("warning();");
debug("debug();");
critical("crticial();");
message("message();");

Which when run results in:

aroman@crackedpipes:~/elementary/switchboard/build$ ./switchboard
[L_WARN 12:38:53.392668] [switchboard-app:354] warning();
[L_FATAL 12:38:53.392936] [switchboard-app:356] crticial();
[L_FATAL 12:38:53.393048] Switchboard will not function properly.
aroman@crackedpipes:~/elementary/switchboard/build$ ^C

So only 2 of the 5 logging functions, including the one in Logger itself,
didn't work.

Am I doing something wrong, or is this a bug?


On Sun, Aug 14, 2011 at 5:27 AM, Lucas Baudin  wrote:

>  Hi,
>
> I don't have the time to write a long mail atm, but in fact, you must call
> g_debug (or debug() in vala), g_warning, g_critical, etc... to log any
> informations using the Granite logger. It will just replace the default glib
> formatter, but you must use the same functions.
>
> Lucas
>
>
> On 08/14/2011 08:26 AM, Avi Romanoff wrote:
>
> Hi,
>
>  I am in the process of giving Switchboard as much Granite love as I can
> before the imminent 1.0 launch. I believe the way logging works in Granite
> right now is pretty broken.
>
>  First off, the only logging function Logger actually provides is
> notification(), which does not even appear to print any message in my test.
> Obviously it should work, and I'll file a bug, but what about other log
> levels? Surely it would make just as much sense to have convenience
> functions for critical/fatal and debugging errors as well?
>
> Additionally it seems to me that Logger being something of a singleton
> makes it massively annoying to log errors in different parts of an
> application, where access to the Logger object might not be available.
> Could/should the logging system be re-factored to accommodate this, or am I
> missing something?
>
>  Avi
>
>
>
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

[Elementary-dev-community] Granite Logger

2011-08-13 Thread Avi Romanoff 
Hi,

I am in the process of giving Switchboard as much Granite love as I can
before the imminent 1.0 launch. I believe the way logging works in Granite
right now is pretty broken.

First off, the only logging function Logger actually provides is
notification(), which does not even appear to print any message in my test.
Obviously it should work, and I'll file a bug, but what about other log
levels? Surely it would make just as much sense to have convenience
functions for critical/fatal and debugging errors as well?

Additionally it seems to me that Logger being something of a singleton makes
it massively annoying to log errors in different parts of an application,
where access to the Logger object might not be available. Could/should the
logging system be re-factored to accommodate this, or am I missing
something?

Avi
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] [Granite] AppMenu modification

2011-08-02 Thread Avi Romanoff 
To go back to the original issue, if I'm understanding it, is that people
would like to have the option of using an appmenu without any pre-loaded
icons. This is the way it used to be with the original AppMenu class that
someone wrote ages ago. When I created the AppMenu class currently in
Granite, I also forced those pre-loaded menuitems that are being discussed.
The idea was basically threefold:

1. Force consistency with the appmenu interface across granite apps.
2. Make it easier for end-developers to add in appmenus (previously your app
would have to explicitly add the appmenus, which would usually result in 10
or so lines of copypasta.
3. I didn't anticipate anyone needing to use the appmenu for anything but..
an appmenu.

I think this comes down to a HIG question. Should appmenus be allowed to be
used for non-appmenu purposes (i.e Xapantu's use in Euclide)? Should
developers be allowed to override the appmenu items?

If the answer is yes to those questions, I think what might make sense is
another constructor for appmenu/some way of creating a "blank" appmenu. That
way we can keep the API simple for people to use an work with, but
allow flexibility where needed.

Avi

On Sat, Jul 30, 2011 at 4:57 PM, Daniel Fore wrote:

> I dunno I think Christian has the right idea here. If it's different enough
> to warrant it's own About, then it should probably be it's own binary,
> separate package, etc.
>
> Best Regards,
> Daniel Foré
>
> www.elementaryos.org
>
> On Jul 30, 2011, at 1:42 PM, xapantu  wrote:
>
> > Hum, it was a good idea to send a mail here before merging apparently...
> >
> > The problem is the principle, I don't like having pre-configurated
> menuitems, with a global variable (which is a GraniteApplication that no one
> uses AFAIK). The bazaar explorer was just an example. We can also take an
> office suite with different application but the same binary, or something
> like that.
> >
> > The problem is that technically, we can't have an AppMenu with different
> About items in the same binary for example. So, it seems that it is clearly
> a limitation, that we could easily avoided if there was a way to configure
> the items. And the global variable is a bad thing, I think everyone will
> agree that ;)
> >
> > I will make a patch tomorrow to show what I mean, because I think I am
> not very clear ^^
> >
> > On 07/30/2011 08:13 PM, Daniel Fore wrote:
> >> Hmm, I think the Appmenu should only really be used on the app's main
> >> window really. It's supposed to contain only actions which apply to
> >> the app globally. So everything it could contain would be duplicated
> >> across windows, wouldn't it?
> >>
> >> Best Regards,
> >>
> >> Daniel Foré
> >>
> >> http://www.elementaryos.org
> >>
> >>
> >>
> >>
> >> On Sat, Jul 30, 2011 at 10:25 AM, xapantu  wrote:
> >>> Hi,
> >>>
> >>> So, currently, there are some hardcoded menuitem in it, which come from
> a
> >>> global application variable, that only maya uses AFAIK. I want to use
> an
> >>> AppMenu for a bazaar explorer, that I will embed in Euclide.
> >>>
> >>> But I don't want to re-add an "About" and "Report a problem" items,
> since
> >>> they are already in the main AppMenu. So, I would like to remove that
> from
> >>> the AppMenu, or at least to add an option which disable them by
> default.
> >>>
> >>> The code is here: lp:~xapantu/granite/appmenu
> >>>
> >>> Opinions?
> >>>
> >>> If everything is ok, I will merge it...
> >>>
> >>> --
> >>> Mailing list: https://launchpad.net/~elementary-dev-community
> >>> Post to : elementary-dev-community@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~elementary-dev-community
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >
> >
> > --
> > Mailing list: https://launchpad.net/~elementary-dev-community
> > Post to : elementary-dev-community@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~elementary-dev-community
> > More help   : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp