Re: i18n bugs in plasma branch 4.3 + in trunk
On Sunday 12 July 2009, Burkhard Lück wrote: > Ping? also: there must be a better way to keep track of these issues than email on a mailing list. esp one that gets traffic like this one. it's too easy to lose things. does the i18n team keep a set of pages on techbase? if not, perhaps there should be such a place under techbase.kde.org/Projects/i18n (or whatever). i'd suggest bugs.kde.org as another option, though it's pretty time consuming to use. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: i18n bugs in plasma branch 4.3 + in trunk
On Sunday 12 July 2009, Burkhard Lück wrote: > Ping? i'm 1000 km from home spending all day looking at houses to move into. this is the first chance i've had to look at anything kde since i left home. so either someone else does it, or it waits until i'm back home on the 24th. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate status
On Monday 13 July 2009, Diego Casella ([Po]lentino) wrote: > By the way, do we *really* need the sidebar ? which sidebar? the one for the timeline? > Each item can be found in the > final release of plasmate > under the menubar, so I was wondering if we can replace it with something > more useful like a directory tree list ... replace what with a directory tree listing of what? this sentence is really too vague for me to answer -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Message extraction in kdebase/workspace plasma
On Monday 13 July 2009, Burkhard Lück wrote: > kdebase/wokspace/plasma in trunk + branch 4.3 has some files with i18n() / > I18N_NOOP() calls and two *.ui files, but these strings are not extracted > to any message catalog, see attached list. * runtime/plasma/scriptengines/javascript/bind_i18n.h with 4 strings either *.h needs to be added to the typeglob Messages.sh or the strings need to be moved to a .cpp file * workspace/plasma/dataengines/soliddevice/soliddeviceengine.cpp with 5 strings * kdebase/workspace/plasma/dataengines/soliddevice/soliddeviceengine.cpp with 176 I18N_NOOP this needs a Messages.sh file * kdebase/workspace/plasma/dataengines/time/timesource.cpp with 15 I18N_NOOP this also needs a Messages.sh file kdebase/workspace/plasma/scriptengines/python/examples/applets/pyclock/contents/ui/analog_clock_config.ui kdebase/workspace/plasma/scriptengines/ruby/examples/applets/clock/contents/ui/analog_clock_config.ui as examples, i'm less concerned about these but for correctness they should be extracted as well. as examples, they should probably be added right to the package themselves. these packages, as examples for others to use, are really not well suited to i18n since scripted widgets that would be shipped alongside a bunch of c++ which is compiled and installed and using kde's l10n module for translations operate completely differently from 3rd party widgets (which include their translations directy inside the package) i'm really unsure which is the "right" direction here, but they are just examples and not actually code that's used by anyone. really, they ought to not be in kdebase at all but some other module for source code examples using KDE technology. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: zui ideas
On Friday 10 July 2009, Chani wrote: > on sunday me, notmart and ruphy came up with some crazy ideas for the ZUI. > here are the notes... better late than never ;) > > zoom 2 (fully zoomed out): > > -the containment is too small to realyl interact with, so put the toolbox > over top. > problem: on small devices the toolbox could be bigger than the containment. > > -if you have one screen there's always space for 4x4 containments, so when > containment-saving is implemented we could have 2 columns of active ones > and 2 columns of saved ones. how would you tell the difference? (saved ones would be "greyed out" and not actually interactive, i suppose?) where would the visualization come from for the saved ones? (snapshot saved to an image when saved?) how often would one switch between saved and un-saved? > you could drag&drop between the areas to load > and save them (although we could have load/save buttons too perhaps). buttons on each activity kinds of sucks as it is. adding more buttons.. mmm... > we might need to record the last screen they were on, for this. when a it already is recorded when the screen is removed. > screen is unplugged, all its containments would be saved out, and show up > in the saved- containment list on either the first screen or all screens. > when it's plugged in again they'd all jump back where they were > automagically. to move a containment from one screen to another, just drag > it there. disabling and saving out unplugged screen activities is a nice idea. keeping screen activities completely separate though makes for some annoyances like having to decide ahead of time which screen a containment should be on, or else be faced with some odd dance like save the containment, go to the other screen and select it to be loaded. the whole save/load thing feels very artificial at that point. i do like the idea of a "make this activity inactive" area, perhaps by simple dragging it there as you note. but i don't think it can or should dominate the screen much if at all. in fact, to me it would make the most sense to just have a strip of inactive activites, sort of like the new add widgets interface will be. or perhaps just replace zooming with such a listing altogether .. perhaps zooming would just put the view into a coverflow-ish mode that lets you flick through the various activities. this would also neatly solve the "buttons on each activity" problem as one set of controls would be shown below and acting on the activity that is currently "front and center". second zoom out could present a nice grid effect if needed .. this might agree nicely with the media center visual goals as well. it would also make keeping different screens separate deadly easy: each one would get it's own row of containments. > oh, and either painting a screenshot of the active containment, or just its > wallpaper, instead of the checkerboard. we want this to be shiny as well as > useful. :) the challenge with replacing the checkerboard is the same as it was a year ago when we discussed it on this list. until those technical issues are resolved, it will remain a problem. painting a screenshot of the active containment just mixes messages: "some of these things are zoomed, but others aren't". confusing. painting the walllpaper of the active containment, or any wallpaper for that matter, means having to be able to clearly distinguish between that background and the containments themselves. that implies a border/shadow painted around containments. that's the technical issue that needs addressing, regardless of what zooming techniques are otherwise used. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: window management ideas
On Friday 10 July 2009, Chani wrote: > what I wanted is window tagging. do windows live long enough for tagging to work? would there be an "always there" tag? how easy is it to tag a window? (this is an interaction design concept) how does tagging interact with activities? (i suppose that's answered in the "windowgroups / pager / ZUI" thread?) what's the average user advantage in this? how much work is saved or how much efficiency gained versus how much time spent messing around with tagging? this feels like a very geek feature that i can't see many people using. i could be wrong but tagging really tends to work when: * the data set is large * the data set is long lived (so value accrues over time) * the data set is shared by many people (so there's value reaped from other's work or by being able to tie several people's work together in unique ways) because of that, tagging works _fabulously_ for things like photo sharing websites and online news aggregation. how well does it work for a small, often/usually temporary, non-shared data set? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: windowgroups / pager / ZUI
On Friday 10 July 2009, Sebastian Kügler wrote: > So today during lunch, Chani, Marco, Rich and I were talking about the ZUI > and the confusion between the ZUI and virtual desktops. We came up with a i really do like the idea of orchestrating windows and activities and hiding virtual desktops from the user as a non-relevant detail. however: > = Example: Work Activity = > > The email client is started, an office application is started, the desktop > contains a folderview with my current project's work document, and some RSS > feeds that are relevant to my work. how do i keep my windows separated, but keep affinity to the same activity? i want my email windows separate from my web browsing separate from my konsole window with it's N tabs open. i am still working on the SAME thing when working with all of them, however. how do i switch quickly to my social networking activity without dumping all my windows? i mean, i do want my email client there always, for instance. for a web browser viewing a new website it's not such a big issue (open another browser window), but for an email or IM client or a web browser viewing a site that can only be viewed in one tab/window at a time this is useless. confusing "activity" with "virtual desktop" feels like a real mistake. i know it fits some people's work flow, but it feels like a very limiting and, tbh, artificial one. and really, any window-centric approach will suffer from problems. maybe make it activity centric instead, e.g.: * new windows that are opened up are not associated with any given activity (and so are shown no matter what activity is selected) * on zooming out one is presented with all activities and can easily switch to another, windows staying where they are * one can also drag-and-tag, or through some other interaction mechanism associate a window from the "all windows" grouping to an activity if it belongs specifically with that one. so switching activities and changing windows by default has no correlation, but one can associate specific windows with an activity. even better would be if i could associate certain documents with an activity, too, which means we'd need to know which documents are currently being viewed/manipulated within an application. we could get there later, however. still, that doesn't solve the very simple problem of "i'd like to hit ctrl-f2 and go to my konsole window". under the activity-is-a-window-group model i'm stuck with either switching my activity when i switch applications (undesirable) or having all applications sharing the same desktop. that's an unfortunate compromise to make. somewhat related, it may make sense to pull into this activity-based panels which could follow the same rules as windows (always there, unless associated with an activity) > = How does the ZUI look like = > > The ZUI could have the background of a faded to black current activity, or > black. if we go this route, it should have a nice background. fading out the current activity will just make it all very confusing as to what is happening. either zoom out or don't, but don't mix modes with some elements zoomed and some not. if each activity occurs in its own window, then providing a nice background is easy. even if we don't, i've found a hackish way to draw shadows around the desktop containments so we'd be covered there. but. ... yes, this proposal skips over the technical "how we'd make this happen" bit. does plasma export a rendering of each activity for this kwin window effect to render on screen? do we create a top level window per activity? depending on those answers, we'll need to further answer things like: how does this work with multiple screens? how do we keep the resources within sanity? etc. > :-) We can also offer a "traditional/simple mode", much like it's now, but > > without ZUI at all. That would just mean keeping what we have now and > removing the zoom-out. in that case, why don't we just rip out activities as a user facing concept in plasma-desktop altogether. there is, at such a point, precisely no point to them existing at all within plasma-desktop. instead, just create one window per activity (hello, overhead) and let the window manager manage them. personally, i don't agree with this part at all. it will serve one purpose only: to remove this feature from people who can't currently use compositing. so .. i think this is a good start to the idea but it needs a lot more rigor applied to shape it into something that's actually implementable. right now it feels like someone saw a demo of gnome shell and got caught up in the idea of a fancy desktop grid effect. the entire idea of "desktop grid is the answer" completely misses the point: it's not really about giving a nice visual arrangement of what already exists (which is just papering over a static system), but making it easy to switch contexts so that "i was doing A" and "now i'm doing B" is reflected in t
Re: windowgroups / pager / ZUI
On Saturday 11 July 2009, Martin Gräßlin wrote: > * GNOME shell (how do they want to implement their activities. Can we get they don't. they are just virtual desktops. gnome shell is a columnar app launcher with integrated recent apps/docs and a fancy "desktop grid" effect with easy add/remove virtual desktop buttons. i don't see any real cross over. > * Compiz (with that change and GNOME Shell Compiz would be dead :-( let's > at least try to not knock them out) does compiz even care about this? do they need to? plasma should continue to work with normal, regular virtual desktops / workspaces so it can continue to work with other wm's. this really ought to be more something that is implemented in kwin with nepomuk helping glue it all together between plasma and kwin. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: not matching Catalog/Export macro names in playground/base
On Monday 13 July 2009, Burkhard Lück wrote: > - who will remember to check that at that time for each single > applet/engine etc ? we (plasma team) would. it wasn't something we've been checking in the past, but we can and should do so in future. moreover, the "it jumped from playground into base" example you gave is not solved by doing it in playground. in fact, that just means we have to keep our eyes on even MORE things, many of which will never see a release. > - in the current state in playground it is impossible to check for proper > i18n with x-test or with a translated message catalog. playground is not meant for release. it is not releasable code. i don't see the point of testing for translations, nor do i see the point in translating that code either. > - it's not that hard to fix this now (change EXPORT macro name -> one line > commit, move some translation catalogs a bit more. it's not hard to fix it when they move over, either. the ones that do have export macros should be fixed, of course, but still my question is why we're getting people to translate this stuff in the first place, as much of it will never exit playground at all. > - who knows all distros already packaging exceptions like networkmanager > with broken i18n (unused catalogs)? well, actually, we do. that's why i mentioned networkmanager. other than the odd exception, distros should NOT be shipping code from playground in the first place. if they do, they have a lot more work than just i18n fixes to do. > > networkmanager is an exception there as it's already being packaged by > > distros. > > Where should the unused the unused catalogs networkmanagement_openvpnui + > networkmanagement_vpncui be pulled in via insertCatalog() Will Stephenson would know this one. > So just decide in each reported case what is right, the macro name or the > catalog name. that's doable within minutes and takes less time writing > these emails. ... and translating all of playground is a waste of dozens of translator's time. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Access kickoff classes outside the library
On Tuesday 14 July 2009, Arno Töll wrote: > I intend to write my own plasma applet where I'd need some > functionalities already implemented in kickoff. Particularly I find the > program menu launcher part very useful and would be glad if I could > reuse this widget in my own code. that code is not intended to be re-used outside of kickoff; the classes are not in a state to be ready to reasonably provide a public API that we can keep binary stable. if there is interest in such a thing, a workspace/libs/plasmamenu could be started, much like plasmaclock, but it would need a maintainer. > This is what the Widget _should_ look like [1] and this is, what the > widget actually looks like [2]? What am I'm doing wrong here? it's expecting a widget, not a popup menu. pass in a non-popup widget and it should work just fine. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How do I get a patch into Plasma?
On Tuesday 14 July 2009, Alec Moskvin wrote: > Could anyone tell me what I'm doing wrong? nothing; your patch just landed right when i was leaving to go out to vancouver. i have not been working this last week due to the move, and so have not been able to actually test and review the patch. perhaps someone else can do so. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
How do I get a patch into Plasma?
Hi all, There's a bug that I found really annoying, so I went through the code, tracked down where it came through, and wrote a patch. I posted the patch on bugzilla one month ago: https://bugs.kde.org/show_bug.cgi?id=178776#c16 However, no one ever responded. About a week ago, I tried posting to the Review Board, but still no one provided any feedback: http://reviewboard.kde.org/r/980/ I would really like to have this tiny, 2-line patch applied, but the tagging of KDE 4.3 is happening in just one week... Could anyone tell me what I'm doing wrong? Thanks, Alec ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Sleep/Hibernate in Lock/Log out plasma applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1031/ --- Review request for Plasma. Summary --- Display Sleep and Hibernate buttons in Lock/Log out plasma applet. By default they are hidden in the config. Functionality is there, some code copied from powerdevil/battery applet. Having more than two buttons visible makes the buttons become too small - maybe someone has an idea to improve the layout? Diffs - trunk/KDE/kdebase/workspace/plasma/applets/lock_logout/CMakeLists.txt 996693 trunk/KDE/kdebase/workspace/plasma/applets/lock_logout/lockout.h 996693 trunk/KDE/kdebase/workspace/plasma/applets/lock_logout/lockout.cpp 996693 trunk/KDE/kdebase/workspace/plasma/applets/lock_logout/lockoutConfig.ui 996693 Diff: http://reviewboard.kde.org/r/1031/diff Testing --- Thanks, Frederik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add next and previous buttons to Frame applet
> On 2009-07-14 21:04:59, Anne-Marie Mahfouf wrote: > > Works well and I don't see anything wrong in code on a quick look. Sebas, > > can you take a quick look as you'll add remote URL support? > > Thanks Arthur for this patch! > > A pause button was also in the wish list... ;) Referring to https://bugs.kde.org/show_bug.cgi?id=165704 - Anne-Marie --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1028/#review1601 --- On 2009-07-14 17:36:08, Arthur Mello wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1028/ > --- > > (Updated 2009-07-14 17:36:08) > > > Review request for Plasma. > > > Summary > --- > > As mentioned on Frame TODO this patch adds buttons to navigate through slide > show. > Buttons appear when mouse is over applet and only when applet is doing a > slideshow. > Example code at TODO put the buttons above the pictue, I placed them on left > and right borders, but I can change this if necessary. > > > Diffs > - > > trunk/KDE/kdeplasma-addons/applets/frame/frame.h 996678 > trunk/KDE/kdeplasma-addons/applets/frame/frame.cpp 996678 > trunk/KDE/kdeplasma-addons/applets/frame/slideshow.h 996678 > trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp 996678 > > Diff: http://reviewboard.kde.org/r/1028/diff > > > Testing > --- > > > Screenshots > --- > > SlideShow buttons > http://reviewboard.kde.org/r/1028/s/142/ > > > Thanks, > > Arthur > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add next and previous buttons to Frame applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1028/#review1601 --- Works well and I don't see anything wrong in code on a quick look. Sebas, can you take a quick look as you'll add remote URL support? Thanks Arthur for this patch! A pause button was also in the wish list... ;) - Anne-Marie On 2009-07-14 17:36:08, Arthur Mello wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1028/ > --- > > (Updated 2009-07-14 17:36:08) > > > Review request for Plasma. > > > Summary > --- > > As mentioned on Frame TODO this patch adds buttons to navigate through slide > show. > Buttons appear when mouse is over applet and only when applet is doing a > slideshow. > Example code at TODO put the buttons above the pictue, I placed them on left > and right borders, but I can change this if necessary. > > > Diffs > - > > trunk/KDE/kdeplasma-addons/applets/frame/frame.h 996678 > trunk/KDE/kdeplasma-addons/applets/frame/frame.cpp 996678 > trunk/KDE/kdeplasma-addons/applets/frame/slideshow.h 996678 > trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp 996678 > > Diff: http://reviewboard.kde.org/r/1028/diff > > > Testing > --- > > > Screenshots > --- > > SlideShow buttons > http://reviewboard.kde.org/r/1028/s/142/ > > > Thanks, > > Arthur > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Patch to support Plasma::PopupApplets in scriptengines
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/964/#review1598 --- Ship it! this actually changes the behaviour of popupapplet, so now is possible to actually set a widget besides reimplementing graphicsWidget() hmm... i think it should have been this way since the beginning (the api of popupapplet is a ctually a bit... sad, but well..) and i like this change, even for c++ applets too.. however, since is still possible to reimplement graphicswidget, this makes setGraphicsWidget useless in those cases, but i guess it depends from the brokeness of popupapplet api in first place, so let's go for it i would say.. - Marco On 2009-07-14 19:23:26, Richard Dale wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/964/ > --- > > (Updated 2009-07-14 19:23:26) > > > Review request for Plasma. > > > Summary > --- > > Add getters and setters for PopupApplet::widget() and > PopupApplet::graphicsWidget() for use in scripting languages. Add a > initScriptingExtenderItem() signal for script engines to connect to and call > their versions of Applet::initExtenderItem() > > > Diffs > - > > trunk/KDE/kdelibs/plasma/applet.h 996721 > trunk/KDE/kdelibs/plasma/applet.cpp 996702 > trunk/KDE/kdelibs/plasma/popupapplet.h 996702 > trunk/KDE/kdelibs/plasma/popupapplet.cpp 996702 > trunk/KDE/kdelibs/plasma/private/popupapplet_p.h 996702 > > Diff: http://reviewboard.kde.org/r/964/diff > > > Testing > --- > > > Thanks, > > Richard > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Patch to support Plasma::PopupApplets in scriptengines
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/964/ --- Review request for Plasma. Summary --- Add getters and setters for PopupApplet::widget() and PopupApplet::graphicsWidget() for use in scripting languages. Add a initScriptingExtenderItem() signal for script engines to connect to and call their versions of Applet::initExtenderItem() Diffs - trunk/KDE/kdelibs/plasma/applet.h 996721 trunk/KDE/kdelibs/plasma/applet.cpp 996702 trunk/KDE/kdelibs/plasma/popupapplet.h 996702 trunk/KDE/kdelibs/plasma/popupapplet.cpp 996702 trunk/KDE/kdelibs/plasma/private/popupapplet_p.h 996702 Diff: http://reviewboard.kde.org/r/964/diff Testing --- Thanks, Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add next and previous buttons to Frame applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1028/ --- Review request for Plasma. Summary --- As mentioned on Frame TODO this patch adds buttons to navigate through slide show. Buttons appear when mouse is over applet and only when applet is doing a slideshow. Example code at TODO put the buttons above the pictue, I placed them on left and right borders, but I can change this if necessary. Diffs - trunk/KDE/kdeplasma-addons/applets/frame/frame.h 996678 trunk/KDE/kdeplasma-addons/applets/frame/frame.cpp 996678 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.h 996678 trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp 996678 Diff: http://reviewboard.kde.org/r/1028/diff Testing --- Screenshots --- SlideShow buttons http://reviewboard.kde.org/r/1028/s/142/ Thanks, Arthur ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Access kickoff classes outside the library
Hello list,
I was wondering, if it is possible to access kickoff classes outside of
the library itself. The kickoff namespace is not documented very well,
so I ask directly here, since I'm somewhat confused of all those classes
in the namespace.
I intend to write my own plasma applet where I'd need some
functionalities already implemented in kickoff. Particularly I find the
program menu launcher part very useful and would be glad if I could
reuse this widget in my own code. Could someone provide my some hints on
how to use this widget in custom code? Do I need some external linkings,
is it even possible just to instanciate and fill my own program widget
without fuss?
I tried a QMenu widget as Plasma::PopupApplet widget by the way, which
looks very buggy. Is this an intended behaviour?
QWidget * MyPlasmaPoupupApplet::widget()
{
QMenu * foo = new QMenu();
QMenu * bar = new QMenu();
bar->addAction("Hello World from submenu");
foo->addAction("Hello World");
foo->addMenu(bar);
return foo;
}
This is what the Widget _should_ look like [1] and this is, what the
widget actually looks like [2]? What am I'm doing wrong here?
[1] http://img232.imageshack.us/img232/4220/73761448.png
[2] http://img88.imageshack.us/img88/5615/61229435.png
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate status
On Tue, Jul 14, 2009 at 16:16, Yuen Hoe Lim wrote: > There isn't much to look at now I think :P If you want I can grab a > bunch of screenshots and post them on a blog or something - unless > there is a rule of sorts against previewing unreleased stuff or the > like? > Hi Yuen, yeah, that's basically the question. Well, if there's no such rule, I'd definitely be interested in some screenshots, when you find the time. Thanks, michael ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate status
There isn't much to look at now I think :P If you want I can grab a bunch of screenshots and post them on a blog or something - unless there is a rule of sorts against previewing unreleased stuff or the like? On 7/14/09, Michael Rudolph wrote: > On Tue, Jul 14, 2009 at 14:09, Artur Souza > (MoRpHeUz) wrote: >> Hello :) >> >> On Monday 13 July 2009, 13:48 Diego Casella ([Po]lentino) wrote: >>> By the way, do we *really* need the sidebar ? Each item can be found in >>> the >>> final release of plasmate >>> under the menubar, so I was wondering if we can replace it with something >>> more useful like a directory tree list ... >> >> Hmmm...remember that we are trying to do this for >> "non-core-developers"...what >> means that it can't look too much developer..it must be beautiful and >> attractiveI really don't know the impact of having menu entries for >> all the >> stuff that is in the sidebar. Maybe making the sidebar something smaller, >> at the >> top (like a toolbar)let's hear aseigo's opinion about this :) >> >> Cheers, >> > > Hello everyone, > > are there already any screenshots available? Or is an early look > restricted only to those who are willing to compile plasmate? > > I really enjoyed the specs that Aaron put up on techbase, but after > reading about the progress every now and then, I'm wondering if we are > on track to meet the goals set forth in said document. > > I did some mockups, back when Aaron posted the specs and I'd like to > update them with what you guys have done so far. Perhaps I can even > come up with some ideas for the sidebar. > > michael > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Jason "moofang" Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate status
On Tue, Jul 14, 2009 at 14:09, Artur Souza (MoRpHeUz) wrote: > Hello :) > > On Monday 13 July 2009, 13:48 Diego Casella ([Po]lentino) wrote: >> By the way, do we *really* need the sidebar ? Each item can be found in the >> final release of plasmate >> under the menubar, so I was wondering if we can replace it with something >> more useful like a directory tree list ... > > Hmmm...remember that we are trying to do this for "non-core-developers"...what > means that it can't look too much developer..it must be beautiful and > attractiveI really don't know the impact of having menu entries for all > the > stuff that is in the sidebar. Maybe making the sidebar something smaller, at > the > top (like a toolbar)let's hear aseigo's opinion about this :) > > Cheers, > Hello everyone, are there already any screenshots available? Or is an early look restricted only to those who are willing to compile plasmate? I really enjoyed the specs that Aaron put up on techbase, but after reading about the progress every now and then, I'm wondering if we are on track to meet the goals set forth in said document. I did some mockups, back when Aaron posted the specs and I'd like to update them with what you guys have done so far. Perhaps I can even come up with some ideas for the sidebar. michael ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate status
Hello :) On Monday 13 July 2009, 13:48 Diego Casella ([Po]lentino) wrote: > By the way, do we *really* need the sidebar ? Each item can be found in the > final release of plasmate > under the menubar, so I was wondering if we can replace it with something > more useful like a directory tree list ... Hmmm...remember that we are trying to do this for "non-core-developers"...what means that it can't look too much developer..it must be beautiful and attractiveI really don't know the impact of having menu entries for all the stuff that is in the sidebar. Maybe making the sidebar something smaller, at the top (like a toolbar)let's hear aseigo's opinion about this :) Cheers, -- Artur Duque de Souza openBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
