Re: Re: Re: refreshing the system tray icons

[Diego Casella ([Po]lentino)]

>
>
> -- Messaggio inoltrato --
> From: Martin Gräßlin 
> To: plasma-devel@kde.org
> Date: Thu, 01 Dec 2011 21:29:12 +0100
> Subject: Re: Re: refreshing the system tray icons
> On Thursday 01 December 2011 21:11:30 Marco Martin wrote:
> > (even tough i'm still not sure if is a good idea to give icon for the
> > applications like say, amarok)
> no it's not, but reality is that it looks very inconsistant and it does not
> look like we would get the applications out of the systray in 4.8.
>
> So from me +1 to monochrome
>
+1 for me too.
The point is we should make the tray more consistent and less cluttered
ihmo, esp. because it kinda disorient "regular users" about the "things"
the tray stores. Be them plasmoids, application's tray icons, or daemons
reminder, the user doesn't care about how they are implemented, but which
actions they provide. S yep, having all monochrome icons is a great
improvement about consistency :)

An other thing that will improve _a lot_ consistency (thus, the user
experience) is to have a default "look" when the tray icon are clicked:
just think about what you see when you click on the battery or device
notifier icons, versus the klipper or kmix ones. (by the way, please
forgive me for not having finished the kmix qml port yet; hopefully this
month i'll be less busy :)
Cheers,
Diego


> Cheers
> Martin
> >
> > --
> > Marco Martin
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: PopupApplet with Qml/JS broken?

[Diego Casella ([Po]lentino)]

Quoting Marco Martin  So,
> It's probably indeed broken in the js bindings (I think it's different
> from the problem in QML tough)
> I hope to have half a second tomorrow to debug the bindings to see
> what's going on (again, i need a clone :p)
> are you on irc tomorrow?

yep, I'll be online from 3:00 pm until midnight :)
Thanks for your help, see you tomorrow !

> Cheers,
> Marco Martin

Cheers,
Diego

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Re: Can't collapse QML plasmoid to icon

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Thu, 14 Apr 2011 18:47:41 +0200
> Subject: Re: Can't collapse QML plasmoid to icon
> On Thursday, April 14, 2011 18:30:36 Diego Casella wrote:
> > [I didn't received any response yet, so I'm posting again since on April
> 28
> > there is the soft freeze fo 4.7, and I'd like to fill the KMix plasmoid
> > review request as soon as I can :)]
> >
> > Hello guys,
> > I'm facing an other problem during the development of the KMix plasmoid
> > replacement. As I wrote on the subject of this email, I can't set a
> > popupIcon for that plasmoid. I've modified the "Service Types" in
> > metadata.desktop to "Plasma/Applet,Plasma/PopupApplet" (I even tried just
> > "Plasma/PopupApplet") and then, inside the main Component.onCompleted
> > function:
> >
> > plasmoid.setMinimumSize(80, 150)
> > plasmoid.popupIcon("audio-volume-high")
>
> perhaps:
>
> plasmoid.popupIcon = "audio-volume-high"
>
> it's a property, not a function :)
>

Oh my bad, I was still thinking of it as its c++ setPopupIcon() equivalent
>.<
However, now now I've noticed an other weird issue: if I declare the applet
as "Plasma/PopupApplet", install the applet, and run kbuildsycoca4, the
widgetexplorer doesn't show the applet at all.
If I declare the plasmoid as "Plasma/Applet,Plasma/PopupApplet", plasmapkg
(and also plasmate) refuses to install it. If I copy it with "cp -r", the
widgets explorer now displays the new plasmoid but, still, it is not
collapsed into an icon when placed in the panel (popupIcon is a QIcon
property btw :).
Pretty weird, isn't it?

>
> --
> 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 Development Frameworks
>
> --
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Can't collapse QML plasmoid to icon

[Diego Casella ([Po]lentino)]

[I didn't received any response yet, so I'm posting again since on April 28
there is the soft freeze fo 4.7, and I'd like to fill the KMix plasmoid
review request as soon as I can :)]

Hello guys,
I'm facing an other problem during the development of the KMix plasmoid
replacement. As I wrote on the subject of this email, I can't set a
popupIcon for that plasmoid. I've modified the "Service Types" in
metadata.desktop to "Plasma/Applet,Plasma/PopupApplet" (I even tried just
"Plasma/PopupApplet") and then, inside the main Component.onCompleted
function:

plasmoid.setMinimumSize(80, 150)
plasmoid.popupIcon("audio-volume-high")

but it's not working at all :(
Anyone can tell me where I'm wrong?
Furthermore (but this is not essential for my plasmoid), seems like I can't
set a custom actions too, just to let you know :)
Cheers,

Diego


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/




-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Can't collapse QML plasmoid to icon

[Diego Casella ([Po]lentino)]

Hello guys,
I'm facing an other problem during the development of the KMix plasmoid
replacement. As I wrote on the subject of this email, I can't set a
popupIcon for that plasmoid. I've modified the "Service Types" in
metadata.desktop to "Plasma/Applet,Plasma/PopupApplet" (I even tried just
"Plasma/PopupApplet") and then, inside the main Component.onCompleted
function:

plasmoid.setMinimumSize(80, 150)
plasmoid.popupIcon("audio-volume-high")

but it's not working at all :(
Anyone can tell me where I'm wrong?
Furthermore (but this is not essential for my plasmoid), seems like I can't
set a custom actions too, just to let you know :)
Cheers,

Diego


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [GSoC] PlasMate: first release proposal

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Sun, 03 Apr 2011 23:01:49 +0200
> Subject: Re: [GSoC] PlasMate: first release proposal
> Hey Diego,
>
> On Thursday, March 31, 2011 20:03:31 Diego Casella wrote:
> > after hearing sebas' interest about GSoC project aimed to release a
> stable
> > version of PlasMate, I've collected some ideas and wrote this very first
> > draft of the proposal [0] :)
> > As always, comments are highly appreciated!
>
> > @sebas: as you suggested, I didn't included the "code refactoring" thing,
> > but I think a little bit of modularization wouldn't hurt; what do you
> think?
>
> It depends, I'm not really against refactoring parts of the code where, the
> goal however needs to be to get a first working version. You've mentioned
> that
> in your proposel already, but I think the focus should shift slightly.


With "polish the code" I meant fix memleaks, remove i18n puzzles and so on;
now I've explained it better, btw :)


> Some hints that would make it more interesting:
>
> - State the goal more clearly, for example in terms of what will be working
> and tested by the end of your GSoC project. I'd personally like to see the
> following:
>
> * working and intuitive complete workflow for creating Plasma "apps"
>  (creating, editing, previewer and publishing)
> * basic debugging facilities for QML Plasmoids (for example a scripting
>  console where your print() output ends up, an object inspector)
>
+1. A scripting console is a great idea, added to the list.
Plus, I've extended that concept for every Plasmoid type, since it is really
useful. It will also partially address the plasmoid sizing issue you
mentioned above ;)


> * Fixing most important problems: plasmoid sizing in the previewer
> (especially
>  when the Plasmoid fails to load, the display explodes and one can't read
> the
>  error messages)
> * The publisher needs a way to export the Plasmoid to a remote device (for
>  example a "publish to device buttons", which makes testing the widget on a
>  target device way easier (can be done using Plasmoid sharing)
> * Improve documentation for writing Plasmoids, covering basic Plasma
> Widgets,
>  UI guidelines, etc.
> * Working workflow for dataengine development
>
> - I'm not entirely sure in how far runnners are really important at this
> point, and how much work is needed for that. It's probably one of the
> features
> that can go onto the afterburner, if it benefits the above goals.
>
> - If you have plans to further maintain and develop Plasmate (which I guess
> is
> your intention anyway, given your track record so far), it would be good to
> note that in your proposal since it makes it more interesting for people.
> The
> purpose of GSoC is to get people involved after GSoC.
>
Oh I thought this was implicit.
Added this too ;)

>
> - The proposal should also have more detailed milestones, I'd propose bi-
> weekly milestones, which take one or more (or one split up ;)) of the above
> points, and specify those in terms of accountable items. This eases also
> the
> mid- and end-term evaluations.
>
I suck with milestones, so please have a look and tell me what do you
think/if something is missing :)


>
> - You haven't mentioned communication in your proposal, additional to the
> usual suspects, status reports would be very much appreciatd. You can tie
> those to the above milestones,
>
> > :)
> >
> > [0]:
> >
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/diego_casella/1
>
> Thanks for the proposal :)
>
You're welcome, Cheers!

Diego


>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[GSoC] PlasMate: first release proposal

[Diego Casella ([Po]lentino)]

Hey guys,
after hearing sebas' interest about GSoC project aimed to release a stable
version of PlasMate, I've collected some ideas and wrote this very first
draft of the proposal [0] :)
As always, comments are highly appreciated!
Cheers,
Diego

@sebas: as you suggested, I didn't included the "code refactoring" thing,
but I think a little bit of modularization wouldn't hurt; what do you think?
:)

[0]:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/diego_casella/1

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: Subject: Re: Subject: Plasmate status

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Fri, 18 Mar 2011 10:31:07 +0100
> Subject: Re: Subject: Re: Subject: Plasmate status
> On Thursday, March 17, 2011 22:52:42 Diego Casella ([Po]lentino) wrote:
> > The editor part, which is the most interesting probably, is already
> plugin-
> >  based (it picks the editor used based on the mimetype).
> >  Crashing the previewer should not be possible anyway, and if it is, it
> > needs fixing in libplasma. In general, scripted plasmoids (which plasmate
> > is all about) cannot crash plasma (or in that case the previewer).
> >
> >  I might be missing something here, in that case, please enlighten me. :)
> >
> > I'll try to pinpoint the problem; these days I was developing a qml
> > plasmoid, and plasmate was pretty crashy :(
>
> Can you send me backtraces of that? I can't see a single crash here, so
> can't
> really do anything about it without bt.
>

hmm ok, seems like the crash comes from the KMix  engine I've been playing
with lately.
If you want, here it is the bt: http://paste.kde.org/7808/
(I'll try to get a more detailed one btw :)
Cheers,

Diego

>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
>


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

A couple of questions about QML Plasma bindings

[Diego Casella ([Po]lentino)]

Hello guys,
as you should've seen in my latest posts in planetkde, I'm working on a
plasmoid version of the standard KMix applet.
I coded it in QML and of course I've taken advantage of the Plasma QML
bindings (they _really_ rocks!!), and now I've got some questions for you:

* I want to give a more elegant and pleasant look to KMix applet, and I need
to access the monochrome svg audio-* icons, but I have no idea about how to
do it.
  In C++ this is vry easy: a simple call
to Plasma::Theme::defaultTheme()->imagePath(svg) and, if the returned path
is not empty I can use it, otherwise I will fallback to
  the standard icon. So, is it possible to expose something similar to the
existing QML Theme component?

* I'd like to show a tooltip when the applet is collapsed into an icon in
the panel but, still, there are no QML bindings to Plasma::ToolTipContent
and ToolTipManager classes.
  Is there any chances to get it exposed to QML?

Anyways, awesome job with the QML/Plasma integration, it's impressive!
Cheers,
Diego

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Re: Subject: Plasmate status

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Thu, 17 Mar 2011 15:11:24 +0100
> Subject: Re: Subject: Plasmate status
> Hey,
>
> On Thursday, March 17, 2011 10:45:37 Diego Casella ([Po]lentino) wrote:
> > > The timeline feature doesn't work for me. Adding a save point doesn't
> > > seem to
> > > do anything, the timeline stays empty. I've not debugged that yet, so
> it
> > > might
> > > be an easy fix. (Not sure though in how far that part is supposed to
> work
> > > in
> > > general.)
> >
> > Probably the guy (don't rememer his nick) that ported the old Workflow
> dock
> > to the standar menu forgot to connect
> > the clicked signal of the "new savepoint" menuitem with the
> > "newSavePoint()" slot :)
>
> I'll have a look at that.
>
> > I was also thinking to write a GSoC proposal about a deep refactoring of
> > PlasMate codebase (plugin-based), since it's not easy to mantain in its
> > current state, make it not crashing if the previewer crashes, add the
> theme
> > creation support, maybe try adding Qt QML editor into plasmate, and make
> it
> > ready for its first release.
>
> I strongly disagree with a "deep refactoring" of the code. It's fairly
> small,
> and I didn't run across any structural problem. In fact, it's very easy to
> get
> hacking on it, and the code bears little to no surprises.
>

Ok, however more modularization wouldn't hurt :)


> The editor part, which is the most interesting probably, is already plugin-
> based (it picks the editor used based on the mimetype).
> Crashing the previewer should not be possible anyway, and if it is, it
> needs
> fixing in libplasma. In general, scripted plasmoids (which plasmate is all
> about) cannot crash plasma (or in that case the previewer).
>
> I might be missing something here, in that case, please enlighten me. :)
>

I'll try to pinpoint the problem; these days I was developing a qml
plasmoid, and plasmate was pretty crashy :(

>
> That said, I'd be willing to mentor a GSoC project with the goal to release
> a
> stable and complete version at the end of it. That excludes anything which
> brings Plasmate further away from a release, though. Plasmate has been
> lingering for too long, we should bring it to a release instead of
> tinkering
> on the codebase.
>
> Oh great :)
If you think it's feasible, I will put my ideas together and fill a
proposal.


> The editor part is interesting, we can go two ways here: Work with Qt
> Creators
> QML editor, or move towards kdevelop and make sure kdevelop understands it
> and
> can auto-propose object properties and their syntax. Neither of those is
> necessary for a 1.0, imo. They're certainly desirable, though.


Agreed.


> > Ok, now back to KMix QML applet =)
>
> Have fun, and thanks for the comments :)
>

You're welcome, cheers!
Diego


> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>
> --
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Plasmate status

[Diego Casella ([Po]lentino)]

>
>
> -- Messaggio inoltrato --
> From: Sebastian Kügler 
> To: plasma-devel@kde.org
> Date: Wed, 16 Mar 2011 23:44:48 +0100
> Subject: Plasmate status
> Hi,
>

I've spent a few days working on various aspects of Plasmate, our little
> Add-
> On creator application. Newest screenshots:
>
> http://vizzzion.org/stuff/screenshots/plasmate-alpha3-startpage.png
> http://vizzzion.org/stuff/screenshots/plasmate-alpha3-editing.png
>

Looks pretty cool indeed :D
Thank you (and also to PovAddict) for the Git migration!

>
> Here's some updates which you might find interesting:
>
> - I've reworked the startpage to be more explanatory and inviting
> - You can now also work on a local project, without importing it (this
> seems
>  very useful for working on QML applets that are already in Git, or on the
>  harddisk
> - The editor now automatically loads the mainscript, when a project is
> opened:
>  more instant-hackability
> - I've converted plasmate to a git repo, git clone kde:plasmate
> - Licensing has been sorted, it's all GPLv2+ now
> - I've packaged Plasmate for openSUSE, installable packages are can be
> found
>  here:
>
> http://download.opensuse.org/repositories/home:/vizzzion/openSUSE_11.4/i586/plasmate-0.1alpha3-1.1.i586.rpm
>
> http://download.opensuse.org/repositories/home:/vizzzion/openSUSE_11.4/x86_64/plasmate-0.1alpha3-1.1.x86_64.rpm
>
> More details:
>
> The docs, as we all know are a bit lacking, but since Plasmate used
> techbase
> embedded pages, it gets better in Plasmate as we add it there. I've started
> adding small code examples to
>
> http://techbase.kde.org/Development/Tutorials/Plasma/QML/GettingStarted#Layouts
> ; Quite fun, actually ... writing small examples in Plasmate, with its
> previewer and then explaining what happens on techbase, including the code.
>
> Editing local projects in place is I think a valuable addition, since it
> allows to just open a plasmoid directory checked out from git. So it
> doesn't
> go through the savesystem, we can probably make the timeline work with it.
>
> The timeline feature doesn't work for me. Adding a save point doesn't seem
> to
> do anything, the timeline stays empty. I've not debugged that yet, so it
> might
> be an easy fix. (Not sure though in how far that part is supposed to work
> in
> general.)
>

Probably the guy (don't rememer his nick) that ported the old Workflow dock
to the standar menu forgot to connect
the clicked signal of the "new savepoint" menuitem with the "newSavePoint()"
slot :)

>
> The nice thing is that the basic workflow works quite well, you're started
> with a new or existing plasmoid in no-time, instant gratification ahead.
>
> I'd like to include the editor's config dialog, its default settings should
> probably be synched with the proposed QML coding style (tab width, etc).
>

That's a nice :)

I was also thinking to write a GSoC proposal about a deep refactoring of
PlasMate codebase (plugin-based), since it's not easy to mantain in its
current state, make it not crashing if the previewer crashes, add the theme
creation support, maybe try adding Qt QML editor into plasmate, and make it
ready for its first release.

Ok, now back to KMix QML applet =)

Cheers,
Diego


> That's it for now  :)
>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re:Re: Plasma services within Javascript (Aaron J. Seigo)

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Wed, 9 Mar 2011 10:02:37 +0100
> Subject: Re: Plasma services within Javascript
> On Tuesday, March 8, 2011, Diego Casella ([Po]lentino) wrote:
> > Hey guys,
> >
> > after a long time without playing with scripted plasmoid, I've noticed
> that
> > using a Service is somewhat broken.
> > I've even tried to follow the steps descibed here [0], of course changing
> > the following line from
> > service = engine.serviceForSource("notification");
> >
> > to
> > service = plasmoid.service("notifications", "notification");
> >
> > but I'm still getting a "TypeError: Result of expression
> > 'plasmoid.service'[undefined] is not a function."
> > Does anybody know where I'm wrong?
>
> palsmoid.service does not exist.
> engine.serviceForSource does.
>
> iow, trust the error messages :)
>

hhmm ok, anyways the example listed in [0] is still not working. Hints about
this?


[0]
http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet#Notifications


>
> > Oh, an other thing, really strange: seems like the "X-Plasma-MainScript"
> > entry is completely ignored. I've tried to start a Js
> > plasmoid , but the previewer shows nothing unless I rename the main
> script
> > from "project_name.js" to "main" ( back in the old days,
> > I set plasmate to name the mainscript as "project_name.js", thus
> > "X-Plasma-MainScript=code/project_name.js", and we had never
> > encountered a problem like this).
> > This issues happens even wihtin plasmoidviewer, so perhaps something
> > changed inside Plasma?
>
> this is working just fine here ... what version of kdelibs and kde-runtime
> are
> you using?
>
>
Oh this is kind of weird. Last night I recompiled KDE (last time I did it
was sunday night), and now it's working good.
/me is still wondering why me and Yuen Hoe had the same issue yesterday ..
Yuen Hoe, can you please verify if the problem still persists after a
rebuild of kdelibs/kdebase-runtime?
Cheers!


> --
> 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 Development Frameworks
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma services within Javascript

[Diego Casella ([Po]lentino)]

Hey guys,

after a long time without playing with scripted plasmoid, I've noticed that
using a Service is somewhat broken.
I've even tried to follow the steps descibed here [0], of course changing
the following line from
service = engine.serviceForSource("notification");

to
service = plasmoid.service("notifications", "notification");

but I'm still getting a "TypeError: Result of expression
'plasmoid.service'[undefined] is not a function."
Does anybody know where I'm wrong?

Oh, an other thing, really strange: seems like the "X-Plasma-MainScript"
entry is completely ignored. I've tried to start a Js
plasmoid , but the previewer shows nothing unless I rename the main script
from "project_name.js" to "main" ( back in the old days,
I set plasmate to name the mainscript as "project_name.js", thus
"X-Plasma-MainScript=code/project_name.js", and we had never
encountered a problem like this).
This issues happens even wihtin plasmoidviewer, so perhaps something changed
inside Plasma?
Cheers

Diego



[0]
http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet#Notifications
-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.

My personal blog: http://polentino911.wordpress.com/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: the next step on the desktop

[Diego Casella ([Po]lentino)]

Sorry for the clutter in my previous email, I forgot to fully clean the body
of the email :(
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: the next step on the desktop

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Sun, 30 Jan 2011 17:22:41 -0800
> Subject: the next step on the desktop
>
> my proposal is this:
>  [...]
> * a new panel layout (TBD: let's work on this together!)
>

Panels, in the current implementation, are shared across different
activities: what about adding an option like "stick to current activity", in
order to achieve different panels for different activities?
That would be great imho because, in some activities I'm using, I don't
really need the default panel with the notification applet, application
launcher and clock, and I would be happy to replace it with a smaller panel
with some "common used applications" launchers, and a big side panel with
microblog and rss plasmoid.
That's just my two cents and use-case, tho :)
Cheers,

Diego


> --
> 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 Development Frameworks
>
>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Sun, 30 Jan 2011 17:38:32 -0800
> Subject: Re: the next step on the desktop
> On Sunday, January 30, 2011, Aaron J. Seigo wrote:
> > my proposal is this:
>
> forgot:
>
> * a selection of pre-made activities (not running) including a trad desktop
> /
> folderview thig
>
> --
> 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 Development Frameworks
>
>
> -- Messaggio inoltrato --
> From: Markus Slopianka 
> To: plasma-devel@kde.org
> Date: Mon, 31 Jan 2011 03:17:00 +0100
> Subject: Re: the next step on the desktop
> Am Montag 31 Januar 2011, 02:22:41 schrieb Aaron J. Seigo:
> > hi...
> >
> > back when we started the path towards plasma i said that we needed to
> > slowly evolve the desktop beyond the desktop folder with icons littered
> on
> > the desktop.
> >
> > now we have activities, kick-ass containments like search and launch and
> > grouping desktop.
> >
> > it is time to go to that next step and move people away from the old
> ways.
> >
> > i was at a friend's house last night where a bunch of people gathered to
> > hang out, chat, play games, etc. there was a desktop system there running
> > plasma desktop with the search and launch containment and a gorgeous
> > translucent panel couresty of kwin.
> >
> > i saw it and hardly recognized it: it looked new, amazing, the next
> thing.
> > it looked amazing.
> >
> > so, here's my suggestion for 4.7:
> >
> > let's try something big and new. let's make that Big Move and step away
> > from ~/Desktop.
>
> Frankly, I like my dumping ground.
>
> > my proposal is this:
> >
> > * by default, Search and Launch on the desktop
>
> What do you mean by that? Full screen SAL like on Plasma Netbook? Then one
> could just use
> that. However, if you mean a SAL plasmoid is the corner of the screen or a
> new top bar
> with a search bar and an extender than displays the icons (or another
> approach that
> combines both metaphors), I'd be fine with that.
> As long as KDE's file search and indexing mechanism is still broken
> ,
> I see more
> frustration than benefit. I could be wrong, though.
>
> > * improve the tasks widget to have some of the nice features of widgets
> > like "smooth tasks" with the mouse over highlights
>
> I'd be happy if I could disable the scroll wheel for starters...
>
>
> > * an "activities" widget (i'll hapilly write it) that sits next to the
> app
> > launcher and when clicked brings up the actvities manager
> > * an activities switcher as a kwin effect (!)
> > * have all activities avaiable in kactivitmanagerd, even if they are
> > "stopped" in plasma-desktop
>
> It seems to me that programmers with their fully cramped task bars (IDE,
> terminals,
> debuggers, SCM frontends,...) are bigger fans of activities than the common
> persons with
> music player and browser open alone and -- if they are cutting edge -- even
> separate chat
> and mail clients.
> Personally, I'd rather have an actually good Dock implementation that
> merges launcher,
> task switcher, and systray in a single icon for each app. But that's
> possibly the former
> Mac user speaking inside me.
>
> I'm willing to try alternative approaches with an open mind, though.
> Especially when I can
> try them in my 4.6 installation (I'm assuming QML plasmoids and activity
> templates can be
> used for that kind of stuff).
> Maybe I can come up with a mockup for something different myself in the
> coming days.
>
> Markus
>
>
>
> -- Messaggio inoltrato --
> From: todd rme 
> To: plasma-devel@kde.org
> Date: Sun, 30 Jan 2011 22:00:13 -0500
> Subject: Re: the next step on the desktop
> On Sun, Jan 30, 2011 at 8:22 PM, Aaron J. Seigo  wrote:
> > hi...
> >
> > ba

Re: Re: Error while building

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: sujith h 
> To: plasma-devel@kde.org
> Date: Sat, 2 Oct 2010 12:13:34 +0530
> Subject: Error while building
> Hi,
>
> I had found an error while building the kdebase. The error actually
> pointed for the requirement saying it needs 0.6.0 version of dbusmenu-qt.
> I had updated the dbusmenu-qt by pulling it from the gitorious. And
> its already updated. Again am facing the same issue with the kdebase build.
> A helping hand to resolve this issue would be very much appreciated.
>
>
> Sujith H
>
> --
> സുജിത് ഹരിദാസന്
> Bangalore
> http://fci.wikia.com/wiki/Anti-DRM-Campaign
>  http://sujithh.info
>
>
Try to move dbusmenu-qt into the last available tag (git checkout 0.6.4.kde
IIRC), then rebuild dbusmenu-qt and kdebase; this did the trick for me. Once
they will fix that issue (Found version ".." sounds ), you can make your
clone to point back to master :)

Diego.

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Need advice about the Authentication framework GSoC project

[Diego Casella ([Po]lentino)]

Hi guys,
as you should know, I'm developing an authentication framework for scripted
plasmoid using the QCA framework. During these last days I was trying to
retrieve, for each key in the local keystore, the list of key IDs which
signed that given key and, consequently, split them by their level of trust
(KDE key, key signed by a KDE key, user key and so on .. ).
Surprisingly, the QCA::PGPKey class doesn't provide this kind of method and,
looking at the qca-gnupg plugin source in[0], there aren't the usual command
switches to show all the signatures for each keys (--list-sigs or
--check-sigs) :(
So now, what should I do? I've a couple of ideas on my mind:
* patch the plugin, and the PGPKey class ;
* use qprocess to call gpg --check-sigs and then parse its output  ;
* write a new qca plugin based on gpgme library, instead of using the
qca-gnupg which relies upon the gpg executable ;
* contact qca mantainer and request for a patch ;
What do you think about it ?
Thanks for your help,
cheers !!

Diego


[0]: http://websvn.kde.org/trunk/kdesupport/qca/plugins/qca-gnupg/gpgop.cpp

-- 
H: Who is Watson without Sherlock Holmes?
G: Watson was a genius in his own right.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

Hi all,
I've updated again the proposal about scripted plasmoid authentication to
better match the emerging needs :)
As usual, any feedback/advice is very appreciated!
Cheers,

-- Diego

Link:
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/diego_casella/t127038771188
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Re: Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Chani 
> To: plasma-devel@kde.org
> Date: Mon, 5 Apr 2010 15:52:07 -0700
> Subject: Re: Subject: Re: [GSoC] Proposal: Authentication for scripted
> plasmoid downloaded from the web
> On April 5, 2010 15:33:00 Diego Casella ([Po]lentino) wrote:
> > Hi all,
> > after reading some comments on my proposal, I've performed a couple of
> > changes on the implementation details and the timeline, so it should fit
> > better the GSoC schedule now :)
> > To be more precise, I've also included improving PlasMate in order to
> show
> > a widget to easily create and manage the private and public keys, along
> > with the possibility to export the public keys.
> > The Publish widget will be improved as well, showing a "Sign" checkbox
> that
> > will allow the developer to choose which key, from the ones previously
> > created, will be used to sign the plasmoid before the install/upload
> > process.
>
> having plasmoid signing in plasmate is a good idea :)
> "create and manage keys", though? that sounds like kgpg's job.
> I would imagine that plasmate would have something like kmail, where you
> can
> choose which key to use for signing, from your existing keys...
>
> although, you might want to add something that makes it easy for people not
> so
> familiar with gpg to get set up. so, hmm.
>
> That's exactly the reason :)
Since plasmate is designed for lowering the bar for contribution to KDE, it
means that almost certainly a tipical user won't be familiar with the
concept of creating keys using kgpg. So that's why I'd like to provide a
simplified widget for these operations. That's also the reason why I want to
keep these keys separated between all the others because, if they aren't
kept divided, the dev could delete the wrong entry by mistake, and this
could be really bad.

> --
> This message brought to you by eevil bananas and the number 3.
> www.chani3.com
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

Hi all,
after reading some comments on my proposal, I've performed a couple of
changes on the implementation details and the timeline, so it should fit
better the GSoC schedule now :)
To be more precise, I've also included improving PlasMate in order to show a
widget to easily create and manage the private and public keys, along with
the possibility to export the public keys.
The Publish widget will be improved as well, showing a "Sign" checkbox that
will allow the developer to choose which key, from the ones previously
created, will be used to sign the plasmoid before the install/upload
process.
By doing this, at the end of the GSoC schedule, plasma will have one
application to authenticate the plasmoids - the plasma widget explorer - and
an other tool to sign them, PlasMate :)
The link to the full proposal is
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/diego_casella/t127038771188
I'm looking for your thoughts and comments,
Cheers

-- Diego
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Chani 
> To: plasma-devel@kde.org
> Date: Sun, 4 Apr 2010 10:56:42 -0700
> Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid
> downloaded from the web
> On April 4, 2010 06:39:10 Diego Casella ([Po]lentino) wrote:
> > Hi guys,
> > sorry for being late, however here it is my proposal for this summer of
> > code.
> > Since, during PlasMate development, we talked a bit about the possibility
> > to verify the plasmoids downloaded from kde-look.org or opendesktop.org,
> I
> > think about it for a while and I came whit the idea to improve
> > plasmaengineexplorer (plus plasmapkg and PlasMate, if there wil be enough
> > time) in order
>
> I assume you mean plasma *widget* explorer ;)
>

You are right, I made a lot of typos in this email >.<

>
> > to use the QCA api to provide plasmoids authentication. Here it is my
> > implementation details (see the full proposal here
> >
> http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/di
> > ego_casella/t127038771188 ):
>
> psst. only mentors have access to that page - note the "private" in the url
> :)
> I suggest you upload your proposal somewhere public as well.
>
> this one should work :)
http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/diego_casella/t127038771188

-- Messaggio inoltrato --
> From: Chani 
> To: plasma-devel@kde.org
> Date: Sun, 4 Apr 2010 11:19:25 -0700
> Subject: Re: [GSoC] Proposal: Authentication for scripted plasmoid
> downloaded from the web
> On April 4, 2010 11:02:30 Marco Martin wrote:
> > On Sun, Apr 4, 2010 at 3:39 PM, Diego Casella ([Po]lentino)
> >
> >  wrote:
> > > Hi guys,
> > > sorry for being late, however here it is my proposal for this summer of
> > > code.
> > > Since, during PlasMate development, we talked a bit about the
> possibility
> > > to verify the plasmoids downloaded from kde-look.org or
> opendesktop.org,
> > > I think about it for a while and I came whit the idea to improve
> > > plasmaengineexplorer (plus plasmapkg and PlasMate, if there wil be
> > > enough time) in order
> > > to use the QCA api to provide plasmoids authentication. Here it is my
> > > implementation details (see the full proposal here
> > >
> http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/
> > > diego_casella/t127038771188):
> > >
> > > My idea is to use the QCA framework in order to verify the signature of
> > > the plasmoids downloaded from kde-look.org, opendesktop.org, or
> > > installed with plasmapkg/PlasMate. This will require patching the
> plasma
> > > widgetexplorer and plasmapkg (and also PlasMate in order to support the
> > > package signing process, if time permits that).
> >
> > This is a must have and was in the todo since day one...
> > as Chani said i'm not sure if is better at Plasma Package level or at
> > a broader thing for all ghns stuff
> >
>
> hmm.
> honestly I think we'll want it at *both* levels in the end.
> the GHNS dialog will need to ask the server about the security rating, so
> some
> sort of server-side support needs writing for that.
> but we also want to check the security of manually downloaded plasmoids
> (or,
> say, a plasmoid that a friend emailed us). so we want it in Plasma too.
>
> it probably makes sense to start it in plasma, and spread it from there. :)
>

Yep !

>
> oh, another thing: the kcm part of the proposal was kinda vague. I expect
> that
> it'll be just a simple thing, and advanced key-management stuff will be
> left to
> programs like kgpg... we don't want to scare people off. :) of course most
> will
> just leave it with the default KDE key anyways.. hrrm... what exactly is
> the
> kcm needed for? can't you just check which keys I trust in my keyring?
>

The idea of the KCM module is to provide a unique place where listing and
showing all the keys saved, with the opportunity to add/delete them, nothing
more :)
Of course if the keys are the ones shipped with KDE/linux distributor, they
will be available in read only mode (however they can be modified by
performing something like an "sudo apt-get upgrade", if updated keys are
available); otherwise, for third-party keys,you can add/delete them if you
trust its releaser.
Using the default keyring is correct, but since we can't tell how many keys
will be pre-installed, and how many others will be installed by the user, I
don't like the idea to pollute the default keyring with all of these.
By the way this is only my opinion, that's why I need your advices :)

>
> --
> This message brought to you by eevil bananas and the number 3.
> www.chani3.com
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[GSoC] Proposal: Authentication for scripted plasmoid downloaded from the web

[Diego Casella ([Po]lentino)]

Hi guys,
sorry for being late, however here it is my proposal for this summer of
code.
Since, during PlasMate development, we talked a bit about the possibility to
verify the plasmoids downloaded from kde-look.org or opendesktop.org,
I think about it for a while and I came whit the idea to improve
plasmaengineexplorer (plus plasmapkg and PlasMate, if there wil be enough
time) in order
to use the QCA api to provide plasmoids authentication. Here it is my
implementation details (see the full proposal here
http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/diego_casella/t127038771188
):


My idea is to use the QCA framework in order to verify the signature of the
plasmoids downloaded from kde-look.org, opendesktop.org, or installed with
plasmapkg/PlasMate. This will require patching the plasma widgetexplorer and
plasmapkg (and also PlasMate in order to support the package signing
process, if time permits that).

Basically, when downloading a scripted plasmoid, the widget explorer will
extract a file containing the signature of the plasmoid, and check its
validity with a set of public keys shipped with KDE, or a set of custom
imported keys (manageable from a KCM module): if the validation process is
successfull against the original KDE keys, the widget explorer will show a
green flag in a corner of the corresponding plasmoid icon, meaning that the
plasmoid has been made from a KDE developer, so you can trust it. If the
validation is successful with a custom key imported by the user, a yellow
flag will be displayed instead, meaning that plasmoid is signed and you
trust the developer who released that plasmoid. If no keys are matched, or
the plasmoid is shipped without a signature file, a red flag will be shown,
meaning "use it at your own risk". Tooltips will be also patched in order to
show these informations.


Any feedback, suggestion or advice is welcome !

Cheers,

-- Diego
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: Plasmate alpha2?

[Diego Casella ([Po]lentino)]

>
> On Mon, Mar 1, 2010 at 11:46 PM, Aaron J. Seigo  wrote:
>
>> On March 1, 2010, Yuen Hoe Lim wrote:
>> > scripted dataengines). So I was thinking it might be a good idea to take
>> > the opportunity and push out a parallel alpha release that, combined
>> with
>> > the 4.4.1 fixes, would provide a much more usable experience.
>>
>> sounds good; i'll whip out a tarball and name it alpha 2 :)
>>
>> > It might also come in handy for the folks joining the Javascript Jam :)
>>
>> agreed.
>>
>> btw, would it be worthwhile to do a plasmate irc meeting and work up some
>> "todo for the release" notes?
>>
>
> Yes, that'd be very nice :) I'd be ok with anything except this weekend.
> What about you moofang? Diego?
>

Fine for me :)

>
>> --
>> 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 Development Frameworks
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

About javascript API, again :P

[Diego Casella ([Po]lentino)]

Hello guys,

I'm trying to adding a theme icon to a PushButton object, but I'm stuck with
it.
I've tried some combinations such as:

pb = new PushButton()
pb.icon = new QIcon("system-search")

or

pb.image = "system-search"

but seems it doesn't work. However, if I do

iw = new IconWidget()
iw.setIcon("system-search")
pb.icon = iw.icon

it works O.o . Any ideas/hints ?

I've also noticed that radio buttons are not mutually exclusive :)
Cheers!

Diego
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: Javascript runApplication() question

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Sat, 20 Feb 2010 03:30:17 -0800
> Subject: Re: Javascript runApplication() question
> On February 20, 2010, Diego Casella ([Po]lentino) wrote:
> > Or, from an other point of view: is it planned to add a KProcess
> Javascript
> > binding for Plasma?
>
> you're looking for the exec DataEngine :)
>

Cool, thanks :)

>
> --
> 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 Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Javascript runApplication() question

[Diego Casella ([Po]lentino)]

Heya folks,

I've noticed in the Javascript API there is a bool runApplication(string
exe[, array args]) [0] function that allows you to run
an executable with optional arguments. If I try running a command-line
executable instead of a GUI one ( for example
runApplication("ls", "my/favourite/directory/") ), returning a bool value is
not useful at all.
So my question is: it is possible to get the string with the result of the
command above?
Or, from an other point of view: is it planned to add a KProcess Javascript
binding for Plasma?
Cheers,

Diego.

[0]
http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API#LaunchApp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Automatic crash report generated by DrKonqi for Plasmate.

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Geoffray 
> To: plasma-devel@kde.org
> Date: Wed, 17 Feb 2010 15:13:37 +0100
> Subject: Automatic crash report generated by DrKonqi for Plasmate.
> Application: plasmate (0.1alpha1)
> KDE Platform Version: 4.4.00 (KDE 4.4.0) (Compiled from sources)
> Qt Version: 4.6.0
> Operating System: Linux 2.6.32-2-amd64 x86_64
> Distribution: Debian GNU/Linux 5.0.4 (lenny)
>
> -- Information about the crash:
> The crash occurs when right-clicking on a recent project in main window.
>
>  -- Backtrace:
> Application: Plasmate (plasmate), signal: Segmentation fault
> [KCrash Handler]
> #5  QBasicAtomicInt::ref (this=0x18136f0, other=...) at
> ../../include/QtCore/../../src/corelib/arch/qatomic_x86_64.h:121
> #6  QUrl (this=0x18136f0, other=...) at io/qurl.cpp:4106
> #7  0x7f53941350df in KUrl (this=0x18136f0, _u=...) at
> /share/src/kde/KDE/kdelibs/kdecore/io/kurl.cpp:472
> #8  0x0042a6af in GitRunner::setDirectory (this=0x181e5a0, dir=...)
> at
> /share/src/kde/playground/plasma/plasmate/savesystem/gitrunner.cpp:76
> #9  0x0042a725 in GitRunner::isValidDirectory (this=0x181e5a0) at
> /share/src/kde/playground/plasma/plasmate/savesystem/gitrunner.cpp:87
> #10 0x0042efbe in TimeLine::loadTimeLine (this=0x1818770, dir=...)
> at
> /share/src/kde/playground/plasma/plasmate/savesystem/timeline.cpp:50
> #11 0x00437807 in MainWindow::loadProject (this=0xdc6ab0, name=...,
> type=...) at /share/src/kde/playground/plasma/plasmate/mainwindow.cpp:531
> #12 0x0041c4c5 in MainWindow::qt_metacall (this=0xdc6ab0,
> _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0x7fff4cb9e3c0) at
> /share/src/build/kde/playground/plasma/plasmate/moc_mainwindow.cpp:96
> #13 0x7f5393d1c647 in QMetaObject::activate (sender=0xe6c110, m= optimized out>, local_signal_index=, argv=0x18136e0)
> at
> kernel/qobject.cpp:3294
> #14 0x0041bbbf in StartPage::projectSelected (this=0xe6c110,
> _t1=...,
> _t2=...) at
> /share/src/build/kde/playground/plasma/plasmate/moc_startpage.cpp:109
> #15 0x0043badb in StartPage::emitProjectSelected (this=0xe6c110,
> name=..., type=...) at
> /share/src/kde/playground/plasma/plasmate/startpage.cpp:427
> #16 0x0043ba8b in StartPage::emitProjectSelected (this=0xe6c110,
> index=...) at /share/src/kde/playground/plasma/plasmate/startpage.cpp:422
> #17 0x0041bab2 in StartPage::qt_metacall (this=0xe6c110,
> _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7fff4cb9e600) at
> /share/src/build/kde/playground/plasma/plasmate/moc_startpage.cpp:90
> #18 0x7f5393d1c647 in QMetaObject::activate (sender=0xf38730, m= optimized out>, local_signal_index=, argv=0x18136e0)
> at
> kernel/qobject.cpp:3294
> #19 0x7f5392ec90e5 in QAbstractItemView::clicked (this=0x18136f0,
> _t1=) at .moc/release-
> shared/moc_qabstractitemview.cpp:331
> #20 0x7f5392ed599c in QAbstractItemView::mouseReleaseEvent
> (this=0xf38730,
> event=0x7fff4cb9f540) at itemviews/qabstractitemview.cpp:1757
> #21 0x7f5392eebdae in QListView::mouseReleaseEvent (this=0x18136f0,
> e=0x18136f0) at itemviews/qlistview.cpp:796
> #22 0x7f53929ff705 in QWidget::event (this=0xf38730,
> event=0x7fff4cb9f540)
> at kernel/qwidget.cpp:7974
> #23 0x7f5392daa73b in QFrame::event (this=0xf38730, e=0x7fff4cb9f540)
> at
> widgets/qframe.cpp:557
> #24 0x7f5392ed88eb in QAbstractItemView::viewportEvent (this=0xf38730,
> event=0x7fff4cb9f540) at itemviews/qabstractitemview.cpp:1589
> #25 0x7f5393d07ff8 in
> QCoreApplicationPrivate::sendThroughObjectEventFilters (this= optimized
> out>, receiver=0xf3ca70, event=0x7fff4cb9f540) at
> kernel/qcoreapplication.cpp:819
> #26 0x7f53929a905c in QApplicationPrivate::notify_helper
> (this=0xd11e90,
> receiver=0xf3ca70, e=0x7fff4cb9f540) at kernel/qapplication.cpp:4238
> #27 0x7f53929affad in QApplication::notify (this=,
> receiver=0xf3ca70, e=0x7fff4cb9f540) at kernel/qapplication.cpp:3822
> #28 0x7f539702d11b in KApplication::notify (this=0x7fff4cba00e0,
> receiver=0xf3ca70, event=0x7fff4cb9f540) at
> /share/src/kde/KDE/kdelibs/kdeui/kernel/kapplication.cpp:302
> #29 0x7f5393d08bdc in QCoreApplication::notifyInternal
> (this=0x7fff4cba00e0, receiver=0xf3ca70, event=0x7fff4cb9f540) at
> kernel/qcoreapplication.cpp:704
> #30 0x7f53929b18eb in QCoreApplication::sendEvent (receiver=0xf3ca70,
> event=0x7fff4cb9f540, alienWidget=0xf3ca70, nativeWidget=0xf70c50,
> buttonDown=, lastMouseReceiver=...,
>spontaneous=true) at
> ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
> #31 QApplicationPrivate::sendMouseEvent (receiver=0xf3ca70,
> event=0x7fff4cb9f540, alienWidget=0xf3ca70, nativeWidget=0xf70c50,
> buttonDown=, lastMouseReceiver=...,
>spontaneous=true) at kernel/qapplication.cpp:2956
> #32 0x7f5392a305b0 in QETWidget::translateMouseEvent (this=0xf70c50,
> event=) at kernel/qapplication_x11.cpp:4368
> #33 0x7f5392a2f75c in QApplication::x11ProcessEvent
> (thi

Subject: Re: Subject: Re: [PATCH] Support for arbitrary main script names in Python plasmoids

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Richard Dale 
> To: plasma-devel@kde.org
> Date: Fri, 12 Feb 2010 23:59:06 +
> Subject: Re: Subject: Re: [PATCH] Support for arbitrary main script names
> in Python plasmoids
> On Fri, Feb 12, 2010 at 10:17 AM, Richard Dale 
> wrote:
> > On Thu, Feb 11, 2010 at 11:34 PM, Diego Casella ([Po]lentino)
> >  wrote:
> >>> -- Messaggio inoltrato --
> >>> From: Richard Dale 
> >>> To: plasma-devel@kde.org
> >>> Date: Thu, 11 Feb 2010 18:37:55 +
> >>> Subject: Re: [PATCH] Support for arbitrary main script names in Python
> >>> plasmoids
> >>> On Thu, Feb 11, 2010 at 6:02 PM, Luca Beltrame <
> ei...@heavensinferno.net>
> >>> wrote:
> >>> > Hello,
> >>> >
> >>> > currently if you use Python plasmoids the main script *must* be named
> >>> > "main.py" because it is hardcoded into pyappletscripts.py. When using
> a
> >>> > different mainscript in the .desktop file (like Plasmate does) this
> will
> >>> > ensure the plasmoid will not run (you get a NameError exception).
> >>> Well currently in Plasmate there is not way to specifiy the main
> >>> script (or main class).
> >>
> >> Actually, the main script and main class names are taken from the
> project
> >> name; if you create a
> >> RubyClock project, Plasmate will create a rubyclock.rb file, with a
> >> MainRubyClock class inside it :)
> >>>
> >>> The Ruby plasmoid implementation doesn't use the Ruby equivalent of
> >>> __dict__, but simply derives the main class name from the main script
> >>> name. So I wasn't sure is you should specifiy a main *class* name in
> >>> Plasmate like FooBar which would give a main script name of
> >>> foo_bar.rb. Or whether you should give a main script name of
> >>> foo_bar.rb the Plasmate form from which the class 'FooBar' is then
> >>> derived.
> >>>
> >>> Currently in Plasmate the name of the applet is used to derive both
> >>> the module (like a namespace), and the name of the class, which I
> >>> think is wrong. For example, if you call your applet FooBar you get:
> >>>
> >>> module FooBar
> >>>  class FooBar< PlasmaScripting::Applet
> >>> ...
> >>>
> >>> I would rather the class was called 'Main' if you don't specifiy a main
> >>> script.
> >>
> >> I'm sorry, but this is wrong: I've taken care of avoiding it since the
> >> beginning
> >> (I also reverted, a couple of days ago, a commit[1] that did exactly
> what
> >> you just
> >> described ).
> > Ah OK - I was testing what the 'The_User' had just commited, which you
> > have reverted. I think the name of the main script was wrong for
> > MainForBar - it should be code/main_foo_bar.rb, and fixing that was
> > why he made the change. Personally if a main script isn't specified I
> > would prefer a class name of 'Main' and main script of 'main.rb' for
> > Ruby.
> I've just commited some changes to the Ruby folder and main script
> name generation in Ruby so that it now works correctly. If you name
> you project FooBar it will be put in a folder called 'foo_bar' and the
> main script will be called 'main_foo_bar.rb'. If you don't follow this
> convention the correct module and class name will not be generated
> when the Ruby script engine tries to load the applet. I also enabled
> creating Ruby Data Engines, as the Ruby api works file.
>
> -- Richard
>
> That's great, thanks :)


> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [PATCH] Support for arbitrary main script names in Python plasmoids

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Luca Beltrame 
> To: plasma-devel@kde.org
> Date: Thu, 11 Feb 2010 19:32:13 +0100
> Subject: Re: [PATCH] Support for arbitrary main script names in Python
> plasmoids
> In data giovedì 11 febbraio 2010 19:16:53, Aaron J. Seigo ha scritto:
>
> > i can't comment on the use of __dict__ (my python-fu is non-existent :)
> but
> > using mainScript() is obviously correct from a libplasma API usage
> > perspective and if this fixes things then yes it should be backported.
>
> Just tested this in Plasmate, which I know uses custom main scripts (after
> working around a bug there), and it works perfectly. My old scripts, which
> use
> "main.py", also work OK.
>
> That's great, thanks =)


> I'll commit to trunk and backport soon.
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: [PATCH] Support for arbitrary main script names in Python plasmoids

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Richard Dale 
> To: plasma-devel@kde.org
> Date: Thu, 11 Feb 2010 18:37:55 +
> Subject: Re: [PATCH] Support for arbitrary main script names in Python
> plasmoids
> On Thu, Feb 11, 2010 at 6:02 PM, Luca Beltrame 
> wrote:
> > Hello,
> >
> > currently if you use Python plasmoids the main script *must* be named
> > "main.py" because it is hardcoded into pyappletscripts.py. When using a
> > different mainscript in the .desktop file (like Plasmate does) this will
> > ensure the plasmoid will not run (you get a NameError exception).
> Well currently in Plasmate there is not way to specifiy the main
> script (or main class).
>

Actually, the main script and main class names are taken from the project
name; if you create a
RubyClock project, Plasmate will create a rubyclock.rb file, with a
MainRubyClock class inside it :)

>
> The Ruby plasmoid implementation doesn't use the Ruby equivalent of
> __dict__, but simply derives the main class name from the main script
> name. So I wasn't sure is you should specifiy a main *class* name in
> Plasmate like FooBar which would give a main script name of
> foo_bar.rb. Or whether you should give a main script name of
> foo_bar.rb the Plasmate form from which the class 'FooBar' is then
> derived.
>
> Currently in Plasmate the name of the applet is used to derive both
> the module (like a namespace), and the name of the class, which I
> think is wrong. For example, if you call your applet FooBar you get:
>
> module FooBar
>  class FooBar< PlasmaScripting::Applet
> ...
>

> I would rather the class was called 'Main' if you don't specifiy a main
> script.
>

I'm sorry, but this is wrong: I've taken care of avoiding it since the
beginning
(I also reverted, a couple of days ago, a commit[1] that did exactly what
you just
described ). Plasmate creates by default a

Main class for ruby and python plasmoids.

So we don't have naming collision :)

>
> For Python, what if there are several classes in the the python main
> script file - how do you tell which one is for the applet you want to
> instantiate?
>
>
> > The attached patch fixes this by retrieving the mainscript file,
> stripping it
> > to its name and then using Python introspection (__dict__) to pass the
> right
> > module name to the CreateApplet call.
> >
> > After applying, old plasmoids (using main.py) and new ones (using *any
> name*)
> > seem to work correctly.
> >
> > OK to commit? Should this also be backported?
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
> >
>

[1]
http://websvn.kde.org/trunk/playground/base/plasma/plasmate/templates/mainPlasmoid.rb
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> From: Yuen Hoe Lim 
>
>> i wonder if a purpose-built tool just
>>> for making theme packages wouldn't be better. what do you think of
>>> dropping
>>> themes from the target use cases?
>>>
>>
>> It's all the same for me. Yuen Hoe, Shantanu, what do you think ?
>>
>
> I'm not really in position to comment knowledgeably because I don't know
> anything about theming (yet). It would probably be a little weird though if
> PlasMate ends up being a complete, one-stop tool for everything else (at
> least for Plasmoids we're close to and aiming for this) but will never be as
> such for themes, if I understood Aaron's point correctly.
>

Agreed, that's my point of view indeed.
By the way, with theme packaging enabled too, PlasMate won't be a complete
Plasma development tool because we still don't provide any Wallpaper plugin
support. And, afaik, there is only python bindings for that (apart from c++,
of course).
So, should we discard theming support, or add Wallpaper support too (for
python at least, and wait for 4.5SC to get  js and ruby bindings) and make
plasmate complete ?
Or simply, release it as it is now, refining the actual features, and listen
to users feedbacks ?

>
> That's my 2cents. I think Aaron and Diego should probably make the final
> decision on this (and Shantanu too if you know ought about theming).
>
> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
> From: "Aaron J. Seigo" 
> > > the javascript DataEngine and Runner APIs are not documented. unless
> > > someone
> > > else get to it, they won't be before 4.5 is out. which is ok, since
> those
> > > Javascript APIs have known (at least to me ;) deficiencies in 4.4.
> those
> > > are
> > > really more 4.5 targets.
> >
> > Ok, so should we disable the js ( and ruby ) radio button when selecting
> a
> > runner or dataEgine project, until we get an improved API  ?
>
> yes, probably makes sense. we should make sure that they are enabled by the
> time KDE SC 4.5 is available, though. but that's 6 months away :)
>

Nice, it's time to ping kde-bindings guys then :)

>
> > > And theme support is still unavailable, in this current state.
> > >
> > > theme support would be fairly easy to add, as far as packaging goes,
> but
> > > it will still require an external tool such as Inkscape for the
> > > forseeable future. so it will never be "perfect" for theming, it really
> > > would be just more of a packaging and previewing tool.
> >
> > Ok, then something like "create the theme directory hierarchy" -> "drag
> and
> > drop svgs and color scheme" -> "preview" -> "publish" should be fine :)
>
> yes, that's all that's needed.
>
> --
> 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 Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Tue, 2 Feb 2010 13:31:02 -0800
> Subject: Re: Subject: Re: plasmate alpha1 release
> On February 2, 2010, Diego Casella ([Po]lentino) wrote:
> > We need to add a dataEngine and runner templates in Javascript, as well a
> > runner template written in ruby but, up to now, i didn't find any example
> > in order to write good templates fot that. Hints ?
>
> the javascript DataEngine and Runner APIs are not documented. unless
> someone
> else get to it, they won't be before 4.5 is out. which is ok, since those
> Javascript APIs have known (at least to me ;) deficiencies in 4.4. those
> are
> really more 4.5 targets.
>

Ok, so should we disable the js ( and ruby ) radio button when selecting a
runner or dataEgine project, until we get an improved API  ?

>
> but i can quite easily provide templates for both, and really should be
> adding
> such things to kdeexamples anyways.
>

Good :)

>

> And theme support is still unavailable, in this current state.
>
> theme support would be fairly easy to add, as far as packaging goes, but it
> will still require an external tool such as Inkscape for the forseeable
> future. so it will never be "perfect" for theming, it really would be just
> more of a packaging and previewing tool.


Ok, then something like "create the theme directory hierarchy" -> "drag and
drop svgs and color scheme" -> "preview" -> "publish" should be fine :)

i wonder if a purpose-built tool just
> for making theme packages wouldn't be better. what do you think of dropping
> themes from the target use cases?
>

It's all the same for me. Yuen Hoe, Shantanu, what do you think ?

>
> > Furthermore, IMO, we should make PlasMate project-centric, for a couple
> of
>
> agreed
>
> --
> 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 Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Wed, 3 Feb 2010 02:28:33 +0800
> Subject: Re: plasmate alpha1 release
>
> I attempted the basic use-case I assumed should work: I start with some
> code, create a save point (this succeeds), then I do new things to the code,
> and then I attempt to revert the code back to the state when I created the
> save point. I don't get any errors or whatnot, but I can't seem to
> successfully revert either.
>

It's because the editor creates a backup copy of the file you are editing
and, since that backup isn't version controlled, git refuses to checkout or
revert to a previous state. Thanks for noticing ( since i turned backup off
:) !
I'll fix it as soon as possible by creating a .gitignore file :)

>
> Hmm, Personally I think I'd feel better with once every 2 months :)
>
> +1

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

Subject: Re: plasmate alpha1 release

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 2 Feb 2010 18:12:03 +0800
> Subject: Re: plasmate alpha1 release
> Hi guys,
>
> would it be reasonable to try for an alpha release with:
>>
>> * tagging on the 8th
>> * release on the 10th, assuming the tagging goes well
>>
>
Good for me too, so we can start recieving feedbacks from the users :)

>
> Sounds awesome! I'm not sure what kind of quality would be expected of
> alpha software though :P
>
Some of my questons/concerns about the present state of PlasMate are as
> follows:
>
>- AFAIK we are only (more or less) good to go for Plasmoids. I think
>runners et al don't quite work. Do we "hide" those options for now? :P
>
> Hiding its not a good idea, i did it this summer and they told me to not do
that; btw i agree with your idea to do something for that :)
We need to add a dataEngine and runner templates in Javascript, as well a
runner template written in ruby but, up to now, i didn't find any example in
order to write good templates fot that. Hints ?
And theme support is still unavailable, in this current state.

>
>- Likewise we currently have some UI stubs for unimplemented features
>(eg. Publish to GHNS), "hide" those too?
>- I haven't really been testing the timeline, and now that I tried it,
>it doesn't seem to work right =( Am I not using it correctly? Or is it
>bugged? Diego could you check? :P
>
> If you would be more detailed, I'll be glad to help you :)

>
>- I can't seem to create a configuration dialog for my (Python)
>plasmoid in PlasMate. I used to override showConfigurationInterface(), but
>that doesn't seem to work while using PlasMate. As long as I set
>hasConfigurationInterface to True and have the "User Interface" folder
>empty, the plasmoid always crashes when I attempt to view the configuration
>interface (right-click > settings). IIRC you're supposed to put
>QtDesigner-generated ui files in "User Interface", if so, does it make 
> sense
>to release now when there's no QtDesigner integration? Or we just leave the
>configuration interface to "future work"?
>- Additional, non-urgent point following from the last: crashing the
>plasmoid crashes PlasMate. This doesn't seem right, but I've no idea how to
>fix it at this point.
>
> What do you all think? If we could solve/get around these then for my part
> I think we're good :)
>

Agree.
Furthermore, IMO, we should make PlasMate project-centric, for a couple of
reasons:

*regardless the type of project started/opened, plasmate now loads the last
layout saved ( moreover, the layout is not resetted when changing project in
the same plasmate session ). Therefore, if we were developing a plasmoid
with the previewer visible, and then we change to a dataengine project to
fix a bug ( or if we start plasmate and open a dataengine project, when the
last project developed was a plasmoid with the previewer on ), the user will
see the previewer even if there is no reason on showing a preview for a
dataengine;

*for each project, we could save the last modified file, and show it the
next time the project will be opened again;


>
>> we should have a release plan from that point forward as well. how about:
>>
>> * a release every month, around the 10th of the month
>> * if changes warrant it and there is the manpower for it, interim releases
>> * aim for first betas in may, this would also include a feature freeze
>> * aim to move it into extragear/sdk/ and release a 0.1 release in tandem
>> with
>> KDE SC 4.5
>>
>
> Sounds good to me, although with only 2-3 devs I'm not sure how many
> changes we'll be able to push each month.
>
> 
> 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
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Wed, 27 Jan 2010 12:45:58 +0800
> Subject: Re: On Plasmate's recent project list
>
> Correct, the project <---> folder naming convention is suggested, not
>> required ( even though I wouldn't break that :P ).
>>
>
> Hmm, okay so this brings up the greater question of whether we want to
> force project and folder names to be identical (They don't have to be
> technically, but we can force it programmatically). I'm personally not keen,
> (I have in fact already broken that rule in the implementation) and here
> again are my list of reasons :P
>
>- Forcing the names to be the same has the benefit of neatness, but I
>don't think this is always desireable since we are allowing users to import
>existing plasmoids as well as download them from GHNS (eventually), and the
>user really has no control over the names of these external projects. It'd
>be pretty troublesome, at least if it was me, if I was blocked from
>importing just because I have a project locally with the same name (note
>that if we force project and folder names to be identical, name conflicts
>will occur even if I have a plasmoid and a runner, for example, with the
>same name, and those are clearly different).
>- I think importing existing plasmoids and stuff will be a fairly
>common use-case, and the project name == folder name rule is not widely
>enforced in existing plasmoids (my own plasmoid doesn't keep this rule..)
>- For the above reasons I'm not convinced that there is a significant
>advantage of forcing project and folder names to be identical, and yet
>forcing them to be identical will make a lot of other sticky
>conflict-resolution dialogs necessary, not just in this 'import-all'
>feature. Examples: the regular project import, import from GHNS or even the
>desktop if we implement that, and when the user changes the project name in
>the metadata editor.
>
> In short, I think forcing the names to be identical will create a lot of
> extra work without really adding any significant benefit. It still can be
> done though if you guys really think it's better. What do you guys think? :)
>
> So,if we bump into a conflict situation, we rename one of the two folder,
>> good. Now, my question is: how the user will be able to distinguish the
>> "current" and "backup" version of his/her project ?
>> I mean, in the project list we can't show the directories name because
>> they must be hidden, so an appropriate way is to pick up the project name
>> from the "Name" field metadata.desktop file, and surprisingly this will be
>> 99% times the same, since previously there was a conflict, so most likely
>> the user will fill a bug report because he/she can't distingiush between the
>> two projects, and he/she is forced to look to the sources in order to find
>> the correct one.
>> So, what about showing the "Remove,overwrite,ignore" buttons, or adding
>> more informations in the project list (for example adding the date of last
>> modification could be enough to distinguish between and old backup and the
>> current project, at least when there are few projects). Any other ideas ?
>>
>
> I maintain that the former only makes sense if we force project names to be
> == folder names (in which case we'd need to add that kind of options/dialogs
> all over the place). If we keep the current status though (project names !=
> folder names), then I agree that we need distinguishers in the list. I was
> thinking adding the author name and version, because it should be relatively
> uncommon for the same guy to create two projects with the same name, so
> showing author should eliminate the larger class of duplicate names that
> result from external imports.
>

+1 for me :)

For people who actually want to maintain two projects of the same name and
> both by me, version number I think is a sensible way for me to distinguish
> between the two (so instead of doing the somewhat uncool thing of having to
> name my projects coolplasmoid_1 and coolplasmoid_2, I could have
> coolplasmoid v1 and coolplasmoid v2. Nicer IMO). Slipups that create same
> plasmoid name and same author and same version can STILL occur, but that
> would hopefully be rare, and again the fix is trivial - the user just needs
> to load either one and check his code, then flip to the metadata editor and
> key in an appropriate version number (or change the name if that's what he
> prefers).
>
> Any other ideas? :)
>
> Yours is good and, since its not a vital component in our app, we could
change its behaviour later, referring on users feedbacks :)


> 
> 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: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 26 Jan 2010 22:01:00 +0800
> Subject: Re: Subject: Re: Subject: Re: On Plasmate's recent project list
>
>> Er, there will be a folder name conflict only if there is a project name
>> conflict, right? Only If I already have a project "abcd" and I import which
>> already contains "abcd", there will be a conflict. Correct me if i'm wrong.
>>
>
> No, there is no hard link between the two (project and folder names), and
> they can be different. Plasmate's current state allows you to have two
> projects with the same name, but folder names obviously must be unique.
> Allowing duplicate names and hiding folder names has actually spared me a
> slew of other potentially sticky conflict situations.
>
> Correct, the project <---> folder naming convention is suggested, not
required ( even though I wouldn't break that :P ).
So,if we bump into a conflict situation, we rename one of the two folder,
good. Now, my question is: how the user will be able to distinguish the
"current" and "backup" version of his/her project ?
I mean, in the project list we can't show the directories name because they
must be hidden, so an appropriate way is to pick up the project name from
the "Name" field metadata.desktop file, and surprisingly this will be 99%
times the same, since previously there was a conflict, so most likely the
user will fill a bug report because he/she can't distingiush between the two
projects, and he/she is forced to look to the sources in order to find the
correct one.
So, what about showing the "Remove,overwrite,ignore" buttons, or adding more
informations in the project list (for example adding the date of last
modification could be enough to distinguish between and old backup and the
current project, at least when there are few projects). Any other ideas ?


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

Subject: Re: Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 26 Jan 2010 13:16:50 +0800
> Subject: Re: Subject: Re: On Plasmate's recent project list
>
>> By the way, we should also add a "Remove project" button or whatever
>> because, in order to test python/ruby/js plasmoid/dataengine/runner, I
>> created a lot of  projects that are no longer needed; so we need a button to
>> do some "spring-cleaning" IMO :)
>>
>
> Yeah I was planning to add that, that's why I was asking if all we needed
> to do to kill a project + git repo is to delete the whole folder :) You
> probably already know this, but in the meantime you could just kill all the
> stuff in ~/.kde4/share/apps/plasmate/ and kill the config files in
> ~/.kde4/share/config/plasmate* to start with a clean slate again :)
>
> Yep, that's why I need something more easy to accomplish that :)

> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
> From: Shantanu Tushar Jha 
>


> And there is even more, in my opinion. When the number of projects becomes
>> relevant, the user could forget how he/she properly named each of them, thus
>> it's easy to create a new project with a name already assigned. So a
>> conflict scenario is more plausible.
>> ( I'm wondering if could be cool to implement a bacukp support over
>> gitorious, when my backend will be available :)
>>
>
> Oh yes, then we have to have a conflict resolution method anyway.
>

Of course we have :) The coolness I was talking is about having version
controlled backup system over gitorious, so you can access it from every pc
with an internet connection, without worrying about in what
folder/pendrive/external drive you put it before formatting the pc.
One click, and you backup all your projects online; an other click ( + cool
anti-conflict method ), and you'll get them back :)

>
>> Either choice could mean losing contact with a lot of the user's previous
>>> work. Also not forgetting that folder names are not exposed to the user, so
>>> folder name conflicts are not visible to the user, and he will probably be
>>> quite bewildered if we suddenly pop up and say "hey you have a conflict!"
>>> when he sees none.
>>>
>>> IMO we should avoid force-overwrite if we can at all, and if Diego is
>>> right (he probably is :P ) then it's pretty trivial to just get PlasMate to
>>> do some under-the-hood renaming and circumvent all the possible problems.
>>>
>>
> Ok, then lets design some generic method for this. When someone gets an
> outline of a method, mail to the list and we can discuss. :)
>

What about performing a sort of sha1sum for each project file, and use it to
perform a check when restoring a backup ?
So, if we find two identical packages names with different hashes, we could
prompt a dialog with the name of the package with an "overwrite" checkbox
and a "details" button to give more infos about the projects. ( That's
reptty rough I know, so what about your opinion?)

Well, I'm going to take my DC examinations, bye >.<

>
>>> 
>>> 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
>>>
>>>
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Tue, 26 Jan 2010 00:11:17 +0800
> Subject: Re: Subject: Re: On Plasmate's recent project list
>
> IMO, the import/export tarball feature will be used only for backup and
>> restore purposes. In that case, forcing an overwrite *will* make sense, and
>> that is what I originally meant. We aren't aiming for a per-project export
>> feature. Think of it as 'Backup All Projects' and 'Restore All Projects'. I
>> hope I'm able to explain what I originally meant.
>>
>> I understood what you originally meant, but why restrict it so? I don't
> personally think it's great to force overwrite and I don't think a conflict
> scenario is all too unlikely - 'Backup All Projects' means I'm saving all
> current my work and bringing it with me.
>

And there is even more, in my opinion. When the number of projects becomes
relevant, the user could forget how he/she properly named each of them, thus
it's easy to create a new project with a name already assigned. So a
conflict scenario is more plausible.
( I'm wondering if could be cool to implement a bacukp support over
gitorious, when my backend will be available :)

There is no guarantee that I won't create some projects and import a couple
> more in my new location before I decide to bring in my old work. You can say
> that the 'correct' way to backup all and restore all is to do the restore
> first thing, but users will do what they want - and then complain when they
> have a problem. And no matter how rare a conflict scenario is, forcing
> overwrite is serious business. We're talking about forcing the user to
> choose between losing whole existing projects, and not being able to import
> groups of projects.
>

I totally agree. We have to keep in mind that our target are
beginner/intermediate developers, thus we have to ease their development
cycle without forcing them on such drastic choices.
By the way, we should also add a "Remove project" button or whatever
because, in order to test python/ruby/js plasmoid/dataengine/runner, I
created a lot of  projects that are no longer needed; so we need a button to
do some "spring-cleaning" IMO :)


> Either choice could mean losing contact with a lot of the user's previous
> work. Also not forgetting that folder names are not exposed to the user, so
> folder name conflicts are not visible to the user, and he will probably be
> quite bewildered if we suddenly pop up and say "hey you have a conflict!"
> when he sees none.
>
> IMO we should avoid force-overwrite if we can at all, and if Diego is right
> (he probably is :P ) then it's pretty trivial to just get PlasMate to do
> some under-the-hood renaming and circumvent all the possible problems.
>
> 
> 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
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Subject: Re: On Plasmate's recent project list (Yuen Hoe Lim)

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Mon, 25 Jan 2010 14:06:53 +0800
> Subject: Re: Subject: Re: On Plasmate's recent project list
> There is also another problem and it still can get sticky :) When importing
> a 'project group' tarball, what happens when there are project folders with
> the same name in the target drive? It doesn't make sense to force an
> overwrite, so we'll need to seamlessly rename the folders underneath (the
> user isn't aware of project folder names, so we can name them whatever we
> want as long as it avoids conflict). Now, renaming the folder will have
> implications for the git repository right...? Or am I just being
> overparanoid again :)
>

Don't worry, git doesn't complain if you rename the root folder :)
That's because git doesn't save a reference to the root project directory,
but it refers to the .git/ containing folder. This sounds pretty the same,
but referring the .git/ parent dir allows you to rename it as you wish,
without worrying about the name.


> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
>
> On Sun, Jan 24, 2010 at 9:58 PM, Shantanu Tushar Jha 
> wrote:
>
>> On 1/24/10, Yuen Hoe Lim  wrote:
>> >>
>> >> Uhm I dont get your concern; if you tar all the plasmate project
>> directory
>> >> for example, and then untar it, you also tar each git project history
>> >> (because every project has its own local git repo). Thus, when
>> untar-ing,
>> >> you'll get both your projetc files and git repo for free :)
>> >>
>> >
>> > Really? That's why I said I don't know much about git. So the git local
>> > repository is wholly contained in the folders themselves? That'll make
>> > things a lot simpler. Does that also mean that if I just delete the
>> project
>> > folder the git repository goes down with it? :)
>>
>> Yep, even I was wondering why you were saying that. The whole git repo
>> info, the packs etc are there in .git. So, AFAIK, just saving the
>> contents will do.
>> I can implement this "backup-n-restore" thing once you're done with
>> the "More Projects" option :)
>>
>> >
>> >
>> >> yes sir !
>> >>
>> >
>> > xD
>> >
>> > 
>> > Jason "moofang" Lim Yuen Hoe
>> > http://yuenhoe.co.cc/
>> >
>>
>>
>> --
>> Shantanu Tushar(UTC +0530)
>> http://www.shantanutushar.com
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 19, Issue 43

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Sun, 24 Jan 2010 19:28:56 +0530
> Subject: Re: Subject: Re: On Plasmate's recent project list
> On 1/24/10, Yuen Hoe Lim  wrote:
> >>
> >> Uhm I dont get your concern; if you tar all the plasmate project
> directory
> >> for example, and then untar it, you also tar each git project history
> >> (because every project has its own local git repo). Thus, when
> untar-ing,
> >> you'll get both your projetc files and git repo for free :)
> >>
> >
> > Really? That's why I said I don't know much about git. So the git local
> > repository is wholly contained in the folders themselves? That'll make
> > things a lot simpler. Does that also mean that if I just delete the
> project
> > folder the git repository goes down with it? :)
>
> Yep, even I was wondering why you were saying that. The whole git repo
> info, the packs etc are there in .git. So, AFAIK, just saving the
> contents will do.
>

Exactly :)
The only thing we have to take care is removing that hidded directory when
the deloper wants to upload the package to kdeapps.org ( when this feature
is implemented, of course =P )


> I can implement this "backup-n-restore" thing once you're done with
> the "More Projects" option :)
>
> >
> >
> >> yes sir !
> >>
> >
> > xD
> >
> > 
> > Jason "moofang" Lim Yuen Hoe
> > http://yuenhoe.co.cc/
> >
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Sun, 24 Jan 2010 00:40:33 +0800
> Subject: Re: On Plasmate's recent project list
>
> But, there should be an option by which the user
>> can 'save' all his/her projects to a file (an archive, maybe) so that
>> it can be used after a system reinstall,
>>
>
> Agree, but I'll think about that a little later - I suspect it's not so
> simple as it is not just a matter of files but also save points (ie the Git
> local repositories) that need to be cleanly migrated.


Uhm I dont get your concern; if you tar all the plasmate project directory
for example, and then untar it, you also tar each git project history
(because every project has its own local git repo). Thus, when untar-ing,
you'll get both your projetc files and git repo for free :)

I've no idea how to do that at the moment. I'm not even sure at the moment
> how to kill a project's git repository when it is being deleted. Need to
> look into that in some time (or insidiously arrow Diego to handle it :P ).
>

yes sir !

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

Subject: Re: On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Fri, 22 Jan 2010 22:33:33 -0800
> Subject: Re: On Plasmate's recent project list
> On January 22, 2010, Yuen Hoe Lim wrote:
> > What do you guys think, does this sound like a sensible solution?
>
> 100% yes from me :)
>

/me agrees too

>
> perhaps instead of "other projects" maybe "older projects", "older
> projects"
> or maybe even just "More projects..."? "other" sounds a bit like they
> belong
> to a different category.
>


>
> but really, that's just a very, very minor nitpick. i completely agree with
> everything else you wrote.
>
> --
> 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 Development Frameworks
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PlasMate ~ UI and other stuff

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel 
> Date: Sun, 18 Oct 2009 23:49:52 +0800
> Subject: PlasMate ~ UI and other stuff
> Hi,
>
> Haven't heard from you (plasmate) guys for awhile, guess you guys are busy
> :) Anyway, just like some input here. As per the quick discussion the other
> day, I recently had the editor component tree widget separated out into a
> new dock widget, so it no longer gets replaced by the katepart that gets
> loaded when you click a file. I've been toying around with the layout and
> dockwidget positionings since - and I can't help thinking that, with the
> addition of this new dockwidget, the whole UI has become awfully cluttered.
> This is about the best layout I can come up with atm:
>
> http://i302.photobucket.com/albums/nn91/yuenhoe/plasmateclutter.jpg
>
> I think the main problem now is that there are too many 'vertical'
> dockwidgets - the timeline, the sidebar, and now the editor tree. Vertical
> dockwidgets only fit naturally on the left/right dockareas, but having three
> of them there, plus the mainwidget in the center, really makes the thing
> so... layered, and crowded. Not to mention virtually unusable on a small
> screen.
>
> Some possible ways around it:
>
>- Make one (or more) of the 'vertical' dockwidgets 'horizontal' so that
>we can fit it snugly on the top dockarea instead. I think the editor tree
>has to stay vertical, so it'd have to be either the sidebar actions menu or
>the timeline widget, both of which I'm loathe to touch without first
>consulting with you all :) Those two are now QListWidget derivatives, and 
> it
>doesn't look like there's an easy way to 'horizontalize' them without
>rewriting quite abit of code.
>
> Yup, I'm currently working on it in order to replace QListWidget with a
more flexible QTableModel ( and the same for the Workflow sidebar );
currently I'm busy because I'm writing a presentation for the LinxDay, so be
patient =)
As regarding the directory tree dock widget, what about setting a
QTableWidget as PlasMate central widget and inserting it as first widget?
We could also insert a new tab for each file the user wants to edit, so we
can have multiple files editing for free :)


>- The old mockups:
>
>http://skitch.com/michaelrudolph/ba3j9/plasmate-editor2
>http://skitch.com/michaelrudolph/ba3cg/plasmate-editor-timeline
>
>suggested an interesting 'overlay' effect for the timeline - and also
>that the timeline be hidden all the time until a button at the bottom is
>clicked.
>
>
Yeah, I love this concept because describes perfectly how should work:
hidden when its not needed, and displayed with a fancy graphics when we need
to provide information/perform new actions ;)

>
>- I dunno... ideas?
>
> Also, it seems like alot of stuff with PlasMate is currently 'hanging'. The
> timeline seems to work nicely, but what's gonna happen with the missing
> publish widget and documentation widget? I've been spending my free time
> hacking away at the editor and previewer and there are certainly plenty more
> work needed with those two but I was just wondering about the larger view of
> the project, since no one seems to be paying much attention to it at the
> moment :)
>
> 
> 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: Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Fri, 11 Sep 2009 09:53:37 +0530
> Subject: Re: Re: Plasmate previewer, again =P
>
>
>>- Green flag: package signed by both KDE and the developer ( =
>>completely trusted );
>>- Blue flag: package signed by KDE, but not by the developer;
>>- Yellow flag: package signed by the developer, but not by KDE;
>>- Red flag: package is not signed ( = install it at your own risk ).
>>
>> How is it known that a package is signed by KDE? Is there some existing
> mechanism or it has to be worked on?
>

This is a new feature, so we have to work on it, sooner or later :P

>
>
>>
>> * The editor works pretty good, I tried it and works perfectly.
>>
> Nice, I see that its now opening the dialog in the project's dir, sweet :)
>

Yes, its a tiny improvement I made some time ago =)
It should also load the project name in the title bar iirc, but when opening
the editor, it disappear ... I have to investigate also on this !

>
>
>> * The previewer is awesome, but its possible to test it with a "fake"
>> package and see if it load it correctly ?
>>
> Right now previewer/test can be used to view installed applets. We are
> unable to "execute" an applet currently.
>
>
>> Ok, i think that's all, now i want your opinion/ideas =)
>> Have a nice day,
>>
>> Cheers !!!
>>
>> --
>>> 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 Development Frameworks
>>>
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 15, Issue 25

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Fri, 11 Sep 2009 10:56:09 +0800
> Subject: Re: Plasmate previewer, again =P
> >> * The previewer is awesome, but its possible to test it with a "fake"
> >> package and see if it load it correctly ?
>
> > can you try it on a real package loaded in plasmate?
>
> Back awhile I tried pointing it to some of my plasmoid source code before
> and it worked, so assuming the timeline/git mechanism stores the packages in
> identical format it should just be a matter of passing in the path as
> argument :P
>

Good :)

>
> I'm a little lost with the other stuff though. Will do some ploughing
> through the current code this weekend :)
>
> 
> 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: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Thu, 10 Sep 2009 16:53:48 -0600
> Subject: Re: Plasmate previewer, again =P
> On September 10, 2009, Diego Casella ([Po]lentino) wrote:
> > > -- Messaggio inoltrato --
> > > From: "Aaron J. Seigo" 
> > > To: plasma-devel@kde.org
> > > Date: Thu, 10 Sep 2009 11:23:26 -0600
> > > Subject: Re: Plasmate previewer, again =P
> > >
> > > On September 10, 2009, Shantanu Tushar Jha wrote:
> > > > As we could not have the meeting on that time as Diego and Aaron were
> > >
> > > busy
> > >
> > > > at Tokamak,
> > >
> > > actually, we showed up on irc at the stated time and waited around ...
> :/
> >
> > yup ...
> >
> > > > It'll be nice to have some status update. Diego what things are
> > > > remaining to be implemented, i.e. which were planned but are not yet
> > > > implemented?
> > >
> > > we put together a really short list of "things to do next"; Diego, do
> you
> > > have
> > > that still?
> > >
> > > Of course !
> >
> > Since up to now the code structure is not as good as we want, the basic
> >  idea was to build a core class that handles our UI stuff, a
> ProjectManager
> >  class to create/load projects and keep track of its files, and other
> >  stuffs. As soon as everything works well, first we have to provide a
> >  secure way to upload the package ( the idea is to use QCA to sign the
> >  package ); second, that is, when an user download a package from our
> >  server, we have to alert the user with one of these signals ( iirc :P ):
> >
> >- Green flag: package signed by both KDE and the developer ( =
> >  completely trusted );
> >- Blue flag: package signed by KDE, but not by the developer;
> >- Yellow flag: package signed by the developer, but not by KDE;
> >- Red flag: package is not signed ( = install it at your own risk ).
> >
> > Also, some improvements on Plasma::PackageMetadata should be done ( if
> >  there are no issues with BC ):
> >
> >- Made method's name more coherent ( for example, if the entry we want
> >  to retrieve is "X-KDE-PluginInfo-Name" and the getter is called
> >  "PluginName()", why the setter is named "setName()" ? it should be
> >  "setPluginName()" ! )
>
> it is setPluginName().
>

Ops, you are right ! These days my brain is completely screwed up ...
The funny part is I used both of them in my code =P

>
> >  ; - extend the API in order to handle more entries (
> >  for example, up to now there is no API call to write the
> >  "X-Plasma-MainScript" entry, so i'm forced to use QFile to open the
> >  metadata.desktop file, and then append that string manually O_o )
>
> that probably belongs either in a subclass or via a
> PackageMetaData::setProperty(const QString &key, const QVariant &value)
> method
> since X-Plasma-MainScript is specific to plasmoid scripting and not to
> packages in general.
>
> > * At present, the TimeLine is broken again because the regexp fix made @
> > Tokamak was wrong: in fact the regexp "^commit [0-9a-ef]+$" always
> returns
> > the entire list of commits! I've adjusted it with
>
> hm. try setMinimal(true) on the QRegExp object.
>
> as for the sha1 hash, try:
>
> "^commit ([0-9a-f])+$"
>
> and then you can use QRegExp::cap(int), and use a while loop like the one
> in
> the QRegExp docu:
>
> while ((pos = rx.indexIn(str, pos)) != -1) {
> list << rx.cap(1);
> pos += rx.matchedLength();
>  }
>
> and cut up the list as you go.
>

Ok, I'll try it as soon as possible =)

>
> > * The editor works pretty good, I tried it and works perfectly.
>
> great :)
>
> > * The previewer is awesome, but its possible to test it with a "fake"
> > package and see if it load it correctly ?
>
> can you try it on a real package loaded in plasmate?
>

I'll have a look !

>
> --
> 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 Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Thu, 10 Sep 2009 11:23:26 -0600
> Subject: Re: Plasmate previewer, again =P
> On September 10, 2009, Shantanu Tushar Jha wrote:
> > As we could not have the meeting on that time as Diego and Aaron were
> busy
> > at Tokamak,
>
> actually, we showed up on irc at the stated time and waited around ... :/
>
yup ...

>
> > It'll be nice to have some status update. Diego what things are
> > remaining to be implemented, i.e. which were planned but are not yet
> > implemented?
>
> we put together a really short list of "things to do next"; Diego, do you
> have
> that still?
>
> Of course !
Since up to now the code structure is not as good as we want, the basic idea
was to build a core class that handles our UI stuff, a ProjectManager class
to create/load projects and keep track of its files, and other stuffs.
As soon as everything works well, first we have to provide a secure way to
upload the package ( the idea is to use QCA to sign the package ); second,
that is, when an user download a package from our server, we have to alert
the user with one of these signals ( iirc :P ):

   - Green flag: package signed by both KDE and the developer ( = completely
   trusted );
   - Blue flag: package signed by KDE, but not by the developer;
   - Yellow flag: package signed by the developer, but not by KDE;
   - Red flag: package is not signed ( = install it at your own risk ).

Also, some improvements on Plasma::PackageMetadata should be done ( if there
are no issues with BC ):

   - Made method's name more coherent ( for example, if the entry we want to
   retrieve is "X-KDE-PluginInfo-Name" and the getter is called "PluginName()",
   why the setter is named "setName()" ? it should be "setPluginName()" ! );
   - extend the API in order to handle more entries ( for example, up to now
   there is no API call to write the "X-Plasma-MainScript" entry, so i'm forced
   to use QFile to open the metadata.desktop file, and then append that string
   manually O_o )

Actual state of PlasMate:
* At present, the TimeLine is broken again because the regexp fix made @
Tokamak was wrong: in fact the regexp "^commit [0-9a-ef]+$" always returns
the entire list of commits! I've adjusted it with "commit\\s[0-9a-f]{40}\\n"
and now works perfectly but, since splitting a string with a regexp also
removes the matched expressions, the sha1hash is not present in the
resulting list so I'm waiting to write an elegant solution before committing
:P
* The editor works pretty good, I tried it and works perfectly.
* The previewer is awesome, but its possible to test it with a "fake"
package and see if it load it correctly ?

Ok, i think that's all, now i want your opinion/ideas =)
Have a nice day,

Cheers !!!

--
> 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 Development Frameworks
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Tue, 25 Aug 2009 10:15:42 -0600
> Subject: Re: Plasmate previewer, again =P
> On Tuesday 25 August 2009, Shantanu Tushar Jha wrote:
> > So guys, how about 1430 UTC on Saturday ?
>
> works great for me if it works for you gusy


great for me too !

>
>
> --
> 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
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Tue, 25 Aug 2009 14:57:55 +0530
> Subject: Re: Plasmate previewer, again =P
>
>
> On Tue, Aug 25, 2009 at 12:45 PM, Aaron J. Seigo  wrote:
>
>> On Monday 24 August 2009, Shantanu Tushar Jha wrote:
>> > Yes, last time Aaron could not join us. So we need to plan another
>> > date/time. I have classes from 0330 to  1200 hrs, any time outside this
>> > range is fine for me. What about you guys? Aaron?
>>
>> i'm in Switzerland right now; either today or Thursday works for me.
>> tomorrow
>> i'm busy and friday is "travel to tokamak" day. then i'm at Tokamak for
>> the
>> next week, which might be a good time to do some Plasmate stuff ;)
>
>
> That means that you'll be available on Saturday, right ? (As on Saturday
> Yuen will be comfortable.).
>

I agree with you, Saturday could be a nice choice both for Yuen and us =)

>
> ( /me dreams about going to Tokamak and meeting the developers face-to-face
> :) )
>
>>
>>
>> --
>> 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
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate previewer, again =P

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Mon, 24 Aug 2009 21:01:19 +0530
> Subject: Re: Plasmate previewer, again =P
>
>
> On Mon, Aug 24, 2009 at 8:45 PM, Aaron J. Seigo  wrote:
>
>> On Monday 24 August 2009, Yuen Hoe Lim wrote:
>> > So I was wondering if I should be attempting to chip in on all the work
>> > Diego is doing now
>>
>> giving Diego a hand would probably be good...
>>
>
> I hope even I can give a helping hand. Diego, do you have some task that we
> can help you with?
>

Iirc, some time ago I wrote an email regarding moving the previewer from the
bottom dock to the central widget, and made it tab-able ( with other
potential editor widgets ) for usability reasons. So, if Aaron agrees, what
about checking if that change is possible ?
By the way, we still need an IRC meeting to sinc() each other imo =)
cheers !!


>
>
>> --
>> 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
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasmate irc meeting next week

[Diego Casella ([Po]lentino)]

Ok, so a good candidate imo could be friday 14, from 13:30 to 17:00 UTC =)


> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Wed, 5 Aug 2009 13:17:16 +0800
> Subject: Re: Plasma-devel Digest, Vol 14, Issue 11
> I'm interning now so I'm only available at about 1230 - 1530 UTC on
> weekdays. On friday and saturday I can go later to 1700 or so :)
>
> On 8/5/09, Shantanu Tushar Jha  wrote:
> > 13:30 to 20:30 hours UTC and, any date after 10th is fine for me. Yuen,
> what
> > about you ?
> >
> > On Tue, Aug 4, 2009 at 7:45 PM, Diego Casella ([Po]lentino) <
> > polentino...@gmail.com> wrote:
> >
> >>
> >> -- Messaggio inoltrato --
> >>> From: "Aaron J. Seigo" 
> >>> To: plasma-devel@kde.org
> >>> Date: Tue, 4 Aug 2009 01:34:45 -0600
> >>> Subject: Plasmate irc meeting next week
> >>> hi ...
> >>
> >>
> >> Hi !
> >>
> >>>
> >>> to everyone who's working on Plasmate, we really need to get a meeting
> >>> where
> >>> we can all sit together on irc for a number of hours and pour through
> the
> >>> code. i'm seeing a lot of basic implementation stuff that needs to be
> >>> changed.
> >>>
> >>> i'll be moved into my new place, more or less, by week's end. so let's
> >>> try
> >>> and
> >>> do this next week.
> >>
> >>
> >>> pick a day and a time and i'll be there, but i think we really need to
> >>> get
> >>> together before things go tooo much further.
> >>>
> >>
> >> In this period I'm online from about 6:30 to 20:30 UTC, in the weekend
> >> that
> >> range may vary due to houseworks and other stuffs =P
> >> So whatever day is fine for me, what about the other guys ?
> >>
> >>>
> >>> --
> >>> 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
> >>>
> >>> ___
> >>> Plasma-devel mailing list
> >>> Plasma-devel@kde.org
> >>> https://mail.kde.org/mailman/listinfo/plasma-devel
> >>>
> >>>
> >>
> >> ___
> >> Plasma-devel mailing list
> >> Plasma-devel@kde.org
> >> https://mail.kde.org/mailman/listinfo/plasma-devel
> >>
> >>
> >
> >
> > --
> > Shantanu Tushar(UTC +0530)
> > http://www.shantanutushar.com
> >
>
>
> --
> 
> 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
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 14, Issue 11

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Tue, 4 Aug 2009 01:34:45 -0600
> Subject: Plasmate irc meeting next week
> hi ...


Hi !

>
> to everyone who's working on Plasmate, we really need to get a meeting
> where
> we can all sit together on irc for a number of hours and pour through the
> code. i'm seeing a lot of basic implementation stuff that needs to be
> changed.
>
> i'll be moved into my new place, more or less, by week's end. so let's try
> and
> do this next week.


> pick a day and a time and i'll be there, but i think we really need to get
> together before things go tooo much further.
>

In this period I'm online from about 6:30 to 20:30 UTC, in the weekend that
range may vary due to houseworks and other stuffs =P
So whatever day is fine for me, what about the other guys ?

>
> --
> 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
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Some problem with Plasmate while loading a package

[Diego Casella ([Po]lentino)]

Hi Shantanu,
that's really strange because I created several projects to ensure the files
were created with the right entries, and it never crashed O.o ; even now it
works fine.
The changes I made in createNewProject deal with filling the main script
file and metadata.desktop with the right entries, and saving some
parameters.
I'm not sure this could be the reason, but now I'm curious to hear from Yuen
or someone else if the problem persists.
By the way, I noticed that if you install PlasMate and then you open
"Desktop Settings", in the "Desktop Activity" -> "Type" list there is a new
entry called StudioPreviewer ... it's a wanted feature or not ?

Cheers !


-- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: Plasma 
> Date: Tue, 4 Aug 2009 11:54:16 +0530
> Subject: Re: Some problem with Plasmate while loading a package
> Casella, please see whats the problem if possible. I'm trying to figure out
> since a long time, but still not getting where's the problem. As you've
> recently changed the createNewProject code, maybe you can get a better idea.
>
> On Tue, Aug 4, 2009 at 1:34 AM, Shantanu Tushar Jha 
> wrote:
>
>> After updating to the latest svn revision of Plasmate, I'm unable to
>> create any projects. That is, if I select create new
>> Plasmoid/Dataengine/Runner, type the value and click Create, Plasmate
>> crashes. I've attached the backtrace. All I can understand is that there is
>> some problem while loadPackage() is called in packagemodel.cpp (feeling a
>> lot sleepy and tired right now).
>> Any idea what might be going wrong?
>>
>> --
>> Shantanu Tushar(UTC +0530)
>> http://www.shantanutushar.com
>>
>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 13, Issue 92

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Mon, 27 Jul 2009 13:43:12 -0600
> Subject: Re: Plasmate Status
> On Monday 27 July 2009, Diego Casella ([Po]lentino) wrote:
> > Note that up to now you have to manually setup the working directory by
> > modifying line 165 in mainwindow.cpp, because
> > that global variable isn't set yet
>
> what's wrong with m_model->package()?
>
> > ( actually the projects directories are
> > saved in $HOME/.kde4/share/apps/plasmate which is not
> > a good choice imo, if we want to focus on beginner developers... what
> about
> > a $HOME/PlasMate_Projects folder instead? )
>
> the point is that they should never have to worry about where the files
> are.
> it's an implementation detail. and polluting the home dir with working data
> sets is not great form.
>

Ok, thanks for explanation :)

>
> > By the way, I need a DataEngine example written in JavaScript, I searched
> > in TechBase, kde-look.org and in various svn
> > modules without result.
>
> i added the first support for those 2 weeks ago, so it's not a mystery why
> you
> didn't find anything on it ;) i (or someone) still needs to do some
> bindings
> for Service as well so such dataengines can reimplement serviceForSource
> sanely.
>

Good, I'll check weekly for updates.

>
> > As regards runners, I looked for examples in TechBase and in
> > kdebase/workspace/plasma/runners, kdeplasma-addons/runners,
> > kdereview/plasma/runners but I only found c++ sources... So probably
> > scripting support for runners is not ready now, and I hid
> > the corresponding button.
>
> please don't hide buttons because they don't work. that's what you do for
> final release only if you don't manage to get them working in the meantime,
> but hiding them during development is an awesome way to ensure they never
> get
> implemented. this is the out of sight, out of mind principle.
>

Ok, I'll reset to the previous status.

>
> and yes, it's possible to write runners with ecma script. as soon as it's
> possible to write something useful with plasmate, i'll do up some examples
> using it. ;)
>
> > who decided that plasmate should use tabs for indentation and random
> > whitespacing in various places, e.g. inside of ()s? or rather, since it's
> > the more important question: why?
>
> ok, i found the offending commits. with otherwise small changes the
> committer
> also reformatted the entire file's ws. that is unacceptable. i will be
> changing the formatting back to the kdelibs style later today.
>

Sorry for the huge mistake, it wasn't my intent to make you waste your time
=(
I'll be more careful when committing.

>
> if you have uncommitted changes, you can expect conflicts, so you should
> commit soon.
>
> going forward, if i see a commit that reformats the ws to something other
> than
> the kdelibs style, i will alert the author and revert the offending commit.
> the author can re-do the work.
>
> --
> 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
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasmate Status

[Diego Casella ([Po]lentino)]

2009/7/27 Artur Souza (MoRpHeUz) 

> On Monday 27 July 2009, 04:31 Diego Casella ([Po]lentino) wrote:
> > Note that up to now you have to manually setup the working directory by
> > modifying line 165 in mainwindow.cpp, because
> > that global variable isn't set yet ( actually the projects directories
> are
> > saved in $HOME/.kde4/share/apps/plasmate which is not
> > a good choice imo, if we want to focus on beginner developers... what
> about
> > a $HOME/PlasMate_Projects folder instead? )
> > Now I'm focusing on building a default enviroment based on the
> > project/language selected, so I'll fix also that pending issue =)
>
> Usually this config paths are given by you, so you don't have to hardcode
> them
> ;)
>

Yep I know, I placed that line only for testing purpose XD
I told Shantanu how to modify it, so he can test its usage until I'll commit
the correct versio !

Cheers !!


> Check this class and method: KStandardDirs::locateLocal  (it's also used on
> startpage.cpp).
>
> This way, Plasmate will use whatever path is set for kde applications to
> store
> stuff.
>
> Cheers!
>
> --
> Artur Duque de Souza
> openBossa Research Labs
> INdT - Instituto Nokia de Tecnologia
> --
> Blog: http://blog.morpheuz.cc
> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> --
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasmate Status

[Diego Casella ([Po]lentino)]

Hi Shantanu,
The timeline is fully committed, you simply have to right-click on the item
to pop-up the menus / trigger the related action =P
Note that up to now you have to manually setup the working directory by
modifying line 165 in mainwindow.cpp, because
that global variable isn't set yet ( actually the projects directories are
saved in $HOME/.kde4/share/apps/plasmate which is not
a good choice imo, if we want to focus on beginner developers... what about
a $HOME/PlasMate_Projects folder instead? )
Now I'm focusing on building a default enviroment based on the
project/language selected, so I'll fix also that pending issue =)

By the way, I need a DataEngine example written in JavaScript, I searched in
TechBase, kde-look.org and in various svn
modules without result.
As regards runners, I looked for examples in TechBase and in
kdebase/workspace/plasma/runners, kdeplasma-addons/runners,
kdereview/plasma/runners but I only found c++ sources... So probably
scripting support for runners is not ready now, and I hid
the corresponding button.

However, why I still see the previewer with default wallpaper and without
the button showed in Yuen's blog ?
I wanna play with them too =D

Cheers !!


> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: Plasma 
> Date: Mon, 27 Jul 2009 01:17:10 +0530
> Subject: Plasmate Status
> So, another 2 weeks, and here comes the Plasmate status report :)
>
> As the CHANGELOG says, we have
>
> 1. Fixed the problem with the project name not taking input.
> (KRestrictedLine issue)
> 2. Plasmate remembers positioning of the docks, and reloads on startup.
> 3. Options to select the scripting language while creating a new project.
> 4. Made some UI changes.
>
> And about the savesystem and Timeline, I believe Deigo is working hard.
> ( Btw, I can't see the Timeline menus and see it in action, just a "Not a
> savepoint" icon. Diego, Am I missing something, or its not commited yet? )
>
> Make it rock !!
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Prospective costs of the 3rd Plasma meeting (Tokamak3)

[Diego Casella ([Po]lentino)]

2009/7/22 Artur Souza (MoRpHeUz) 

> Hi Celeste!
>
> On Wednesday 22 July 2009, 12:28 Celeste Lyn Paul wrote:
> > Looks like a good proposal; however, we have some questions before we can
> > make a decision. We would like to see 1 or 2 new people attend this
> > meeting. From the list on techbase, everyone looks familiar. Do you have
> > any new people you have invited or plan to invite who may not be on the
> > list? Fresh blood is one of the things we to see for funded Developer
> > Sprints.
>
> That's true and it's awesome that you remembered about this :). We have
> GSoC
> students like Diego and Ana that have never been to a developer sprint
> before.
> Ana was in Akademy and Diego couldn't go to Akademy and it's probably worth
> it
> checking with him about his availability for Tokamak (I'm ccing him).
> Diego,
> are there any chances that it would be possible for you to attend Tokamak ?


Hi Artur, thanks a lot for asking for our attendance =)
I just sent some emails to my lecturers because usually, in september, there
is
a "special exam session" ( before the new academic year ). As soon as they
reply to me, I'll confirm my participation !!

>
>
> It would also be great to have Ana there as she is mentored by Ivan who is
> coming too. The problem with bringing brazilians is that it tends to be
> expensive and that includes me too. But it would be awesome to have her
> working
> on her project with her mentor during Tokamak (the same apply for Diego as
> he's
> working on Plasmate and his mentors - me and Ricardo - will be there too).


That's a wonderful news !
I really hope to attend this Tokamak so I can meet you, at last =)
( even at the cost to bring some books with me! )

>
> From what I've heard about Ana, as she is a student, there is no way for
> her to
> pay any amount of the air tickets, so we would need 100% sponsorship for
> her if
> she is available. Unfortunately, I also can't afford more than 20% of the
> price
> of the ticket and that increases a little bit the cost of the whole thing
> (making some "head-math" I would say that from 3015 EUR we would go to ~
> 4115
> EUR just for air tickets to have both students there).
>
> What do you think Celeste ?
>
> Cheers!
>
> PS: I'm ccing the students to know if they're available on the dates.
>
> --
> Artur Duque de Souza
> openBossa Research Labs
> INdT - Instituto Nokia de Tecnologia
> --
> Blog: http://blog.morpheuz.cc
> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> --
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 13, Issue 60

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Tue, 21 Jul 2009 18:59:49 +0530
> Subject: Re: Plasma-devel Digest, Vol 13, Issue 55
>
>
> On Tue, Jul 21, 2009 at 3:28 PM, Diego Casella ([Po]lentino) <
> polentino...@gmail.com> wrote:
>
>>
>> On Mon, Jul 20, 2009 at 7:29 PM, Yuen Hoe Lim wrote:
>>>
>>>> Yep, it doesn't seem to accept regular expressions - but a string
>>>> containing every permitted character..
>>>>
>>>>
>>>> http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKRestrictedLine.html#f30d883fc60f67be39e8ffa039842cd6
>>>>
>>>> I've tried, and it actually does allow me to type every character in
>>>> the expression (like '[' and '$') =/ It doesn't seem like a pretty
>>>> thing to do 'qwertyQWERTY012345etcetc' so maybe we could try a regular
>>>> KLineEdit and do some form of validation?
>>>
>>>
>>> For that we've to find out what characters make a valid project name (if
>>> there is a restriction as such, say, on name of a Plasmoid).
>>> Help wanted from others. Guys?
>>>
>>
>> Sorry but yesterday morning I was @ university, and in the evening I
>> compiled KDE 4.4 =P
>>
>
> You mean trunk, right? ;)
>

Yep, but 4.4 sounds sooo sexy =)

>
>
>> By the way today I had a look to the code, fixed ( seems it works fine,
>> however tell me if something is wrong ) and committed.
>> The key point ( imo ) is that by typing:
>>
>> QRegExpValidator *pluginname_validator = new
>> QRegExpValidator(ui->projectName);
>>
>>
>> you are simply telling to pluginname_validator "Hey, your parent is a
>> QObject reference called projectName"; but also a QWidget
>> could be a valid parent, or a QString. It doesn't know how to parse a
>> regular expression with a given QObject reference, that's up to us.
>> However, I removed all QRegExp* statement from setupWidgets(), and
>> connected signals from projectName to a slot I created to
>> parse the text and find unwanted characters. Let me know if it works !
>>
>
> Yep, it works as expected. Also, I think now KRestrictedLine is not
> necessary now. So I've replaced it with KLineEdit to keep things simple.
>

Nice, I forgot to modify it !

>
>
>
>>
>> P.S.: after upgrading to KDE4.4, PlasMate menu has changed: now it shows
>> entries like "Game", "Edit", "Move", "View", "Go",
>> and "Bookmarks", "Tools" O.o
>>
>
> No, that doesn't happen here. Maybe some problem with your installation.
>

That's strange because, before building trunk, I deleted all old
configuration and build files...well, let's try again ..

>
>
>
>>
>> The same problem appears with KTorrent.
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 13, Issue 55

[Diego Casella ([Po]lentino)]

> On Mon, Jul 20, 2009 at 7:29 PM, Yuen Hoe Lim  wrote:
>
>> Yep, it doesn't seem to accept regular expressions - but a string
>> containing every permitted character..
>>
>>
>> http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKRestrictedLine.html#f30d883fc60f67be39e8ffa039842cd6
>>
>> I've tried, and it actually does allow me to type every character in
>> the expression (like '[' and '$') =/ It doesn't seem like a pretty
>> thing to do 'qwertyQWERTY012345etcetc' so maybe we could try a regular
>> KLineEdit and do some form of validation?
>
>
> For that we've to find out what characters make a valid project name (if
> there is a restriction as such, say, on name of a Plasmoid).
> Help wanted from others. Guys?
>

Sorry but yesterday morning I was @ university, and in the evening I
compiled KDE 4.4 =P
By the way today I had a look to the code, fixed ( seems it works fine,
however tell me if something is wrong ) and committed.
The key point ( imo ) is that by typing:

 QRegExpValidator *pluginname_validator = new
QRegExpValidator(ui->projectName);


you are simply telling to pluginname_validator "Hey, your parent is a
QObject reference called projectName"; but also a QWidget
could be a valid parent, or a QString. It doesn't know how to parse a
regular expression with a given QObject reference, that's up to us.
However, I removed all QRegExp* statement from setupWidgets(), and connected
signals from projectName to a slot I created to
parse the text and find unwanted characters. Let me know if it works !

P.S.: after upgrading to KDE4.4, PlasMate menu has changed: now it shows
entries like "Game", "Edit", "Move", "View", "Go",
and "Bookmarks", "Tools" O.o
The same problem appears with KTorrent.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 13, Issue 41

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Fri, 17 Jul 2009 01:13:23 +0800
> Subject: Re: Re: Plasmate status
> >> > With a directory tree listing the project files, of course =)
> >>
> >> isn't that already there? or did someone remove it?
> >>
> >
> > I've never seen that dock widget =(
>
> It's there, though I doubt it's actually doing anything now since
> we're not saving anything yet afaik. Plus its there when you start
> out, but it gets replaced with the editor kpart when you select
> anything.
>

Uh ok, the one with "Configuration Definition", "Images", "Executable
Scripts", "Translations" !!!
I was referring to a traditional directory tree list, with a root directory,
its subfolders and files,
not a list of elements grouped by its usage =)
Sorry for the mistake !

--
> 
> 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
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate status

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Wed, 15 Jul 2009 08:04:31 -0600
> Subject: Re: Plasma-devel Digest, Vol 13, Issue 33
> On Wednesday 15 July 2009, Diego Casella ([Po]lentino) wrote:
> > > -- Messaggio inoltrato --
> > > From: "Aaron J. Seigo" 
> > > To: plasma-devel@kde.org
> > > Date: Wed, 15 Jul 2009 00:10:29 -0600
> > > Subject: 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?
> >
> > Sorry, I was referring to the "Workflow" sidebar, the one with the "Start
> > Page",
> > "Edit", "Publish" and "Doc" items ..
> > As I previously said, all these commands will be redundant in the final
> > release of plasmate,
> > in my opinion. So we could replace it with something more useful.
>
> hm. well ... "start page" is probably unnecessary, as is "edit" (given the
> list of package entries) but a few items like publish, save point, refresh
> preview, etc would make for nice toolbar entries.
>

That makes sense ... I'll modify it as soon as possible.


> > > > 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
> >
> > With a directory tree listing the project files, of course =)
>
> isn't that already there? or did someone remove it?
>

I've never seen that dock widget =(


> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Wed, 15 Jul 2009 08:15:18 -0600
> Subject: Re: Plasmate status
> On Wednesday 15 July 2009, Diego Casella ([Po]lentino) wrote:
> > I've attached some screenshots showing the current interface and the
> > timeline I'm coding;
>
> branches ... it's neat to see that in there, but let's be sure to keep them
> as
> a detail for more advanced usage. people using plasmate should not need to
> understand anything about revision control systems to use it.


Ok, so with which synonym should I use instead of "branch" ?
I was thinking about something like "sector" or "section" ( "create/switch
section"  sounds better IMO ),
however I'm open to your suggestion !

>
>
> > P.S. : /me thinks that could be a good idea starting a personal blog too
> =P
>
> yes :)
>
> --
> 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
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 13, Issue 33

[Diego Casella ([Po]lentino)]

> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Wed, 15 Jul 2009 00:10:29 -0600
> Subject: 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?


Sorry, I was referring to the "Workflow" sidebar, the one with the "Start
Page",
"Edit", "Publish" and "Doc" items ..
As I previously said, all these commands will be redundant in the final
release of plasmate,
in my opinion. So we could replace it with something more useful.

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

With a directory tree listing the project files, of course =)
So the user can double-click on the source to start edit it, or he can drag
an existing
file into, to automatically save it as a project file and open the editor.

>
> --
> 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
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasmate status

[Diego Casella ([Po]lentino)]

Hi guys,
other two weeks are gone, so it's time  to sinc() with each other about
PlasMate status, IIRC =)
Now the TimeLine loads all the commits within the current branch, and also
all the commits that lead
to that branch ( I'm thinking to make  that feature selectable by user, to
decrease the widget length ).
For each item, a tooltip shows the author who made the commit, the date and
the stored message.
In the top of the list is located the current working state of the project,
marked as "Not Saved".
The lower item holds the working branch, and its tooltip shows the other
available branches.
I also modified the GitRunner class, because the previous implementation
caused the app to not close.
Now I'm working on handling properly signals and slots, so we can have an
almost working timeline
within this week !
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 ...
Let me know about this, and also your ideas; lets make PlasMate rocks =)

Cheers !!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasmate Status

[Diego Casella ([Po]lentino)]

Yep, you're right !
As you saw in the mailing list, there was a problem with managing the git
pluging, which was *partially* resolved.
In fact the code suggested wasn't totally correct, so I started to talk with
apaku, a  KDeveloper and Plugin designer,
and I discovered that first, I have to subclass the ShellExtension class in
order to setup the KDevplatform stuff, then init()
that class, after that retrieve a reference to the Core and use it to
retrieve the IPluginController by calling pluginController().
Nice, but an other problem arose:
when calling pluginForExtension() to recieve a pointer to the git plugin, it
returns an invalid pointer all the times =(
Talking to apaku, the reason is because i set-up the Core class with the
option Core::NoUi, and git sometimes wants to show some gui stuff,
like committing with comments. Besides, initalizing the Core with
Core::Default creates a full KDevelop gui, which is not our goal !
So, under his suggestion, now I'm using the plugins/git/gitplugin.cpp and
I'm modifying the source for our purposes =)
I'll commit it as soon as it compiles ( and also works =P ).
Good luck with you exams,

Cheers !!





-- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Mon, 29 Jun 2009 17:58:02 +0530
> Subject: Plasmate Status
> Hi all !
> Last IRC meet we had decided that we'll have a mail about the current
> development status of Plasmate every two weeks. It has been two weeks
> since.
> AFAIK, moofang is working on the previewer on the ideas discussed
> earlier and Diego is working on the Git integration using
> kdevplatform.
> I've not been able to write any code as I've final exams right now.
> Will join moofang after my exams end on 10th next month.
> Guys, add more info about the things I missed.
> Lets make Plasmate rock :)
>
> --
> Sent from Gmail for mobile | mobile.google.com
>
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: PlasMate && KDevplatform issue

[Diego Casella ([Po]lentino)]

I was in wrong, I talked with aseigo and fabo and the plugin is located in
$KDEDIR/lib/kde4/kdevgit.so
so everything is ok, I'll continue on my work =)
 btw thanks for your help !!

-- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Wed, 24 Jun 2009 02:31:15 +0530
> Subject: Re: Re: PlasMate && KDevplatform issue
> I've built the module. Was not sure so I've attached the ls -r output
> of the include and lib dirs. See if you can find what you're trying to
> confirm. (I guess its the same for me, the files aren't there).
>
> On Wed, Jun 24, 2009 at 12:00 AM, Diego Casella
> ([Po]lentino) wrote:
> > Hi guys,
> > I'm  a bit in trouble with compiling kdevplatform module where the git
> > plugin is located.
> > In fact, compiling that module doesn't copy the include headers
> > from$HOME/kdevplatform/plugin/git folder
> > under $KDEDIR/include/kdevplatform/...
> > Same for the libraries, in the $KDEDIR/lib/kdevplatform there are only
> CMake
> > files.
> > I tried to modify by hand the CMakeLists.txt in git/ subfolder, without
> > results.
> > Any suggestion on how make it correctly installed ??
> > Have a look if the problem is present also in your pc, thanks =)
> >
> > Diego.
> >
> >
> >>
> >> -- Messaggio inoltrato --
> >> From: "Artur Souza(MoRpHeUz)" 
> >> To: plasma-devel@kde.org
> >> Date: Mon, 22 Jun 2009 12:36:34 -0300
> >> Subject: Re: PlasMate previewer
> >> On Monday 22 June 2009, 11:57 Shantanu Tushar Jha wrote:
> >> > I was wondering if we should have something like a CHANGELOG for
> >> > plasmate where we can put information about new functionality, and so
> >> > on. Is it possible ?
> >>
> >> Sure, just create a Changelog file on plasmate dir.
> >> So everybody got the svn access ? Diego, did you have any problems as it
> >> seems
> >> you're the only who did not commit anything yet ?
> >>
> >> Cheers,
> >>
> >> --
> >> Artur Duque de Souza
> >> OpenBossa Research Labs
> >> INdT - Instituto Nokia de Tecnologia
> >> --
> >> Blog: http://blog.morpheuz.cc
> >> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> >> --
> >
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
> >
>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: PlasMate && KDevplatform issue

[Diego Casella ([Po]lentino)]

Thanks Shantanu,
it seems we have the same problem =(
I'll look for further information on irc and kdevelop forum.
Thanks for your help,
Diego.


-- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Wed, 24 Jun 2009 02:31:15 +0530
> Subject: Re: Re: PlasMate && KDevplatform issue
> I've built the module. Was not sure so I've attached the ls -r output
> of the include and lib dirs. See if you can find what you're trying to
> confirm. (I guess its the same for me, the files aren't there).
>
> On Wed, Jun 24, 2009 at 12:00 AM, Diego Casella
> ([Po]lentino) wrote:
> > Hi guys,
> > I'm  a bit in trouble with compiling kdevplatform module where the git
> > plugin is located.
> > In fact, compiling that module doesn't copy the include headers
> > from$HOME/kdevplatform/plugin/git folder
> > under $KDEDIR/include/kdevplatform/...
> > Same for the libraries, in the $KDEDIR/lib/kdevplatform there are only
> CMake
> > files.
> > I tried to modify by hand the CMakeLists.txt in git/ subfolder, without
> > results.
> > Any suggestion on how make it correctly installed ??
> > Have a look if the problem is present also in your pc, thanks =)
> >
> > Diego.
> >
> >
> >>
> >> -- Messaggio inoltrato --
> >> From: "Artur Souza(MoRpHeUz)" 
> >> To: plasma-devel@kde.org
> >> Date: Mon, 22 Jun 2009 12:36:34 -0300
> >> Subject: Re: PlasMate previewer
> >> On Monday 22 June 2009, 11:57 Shantanu Tushar Jha wrote:
> >> > I was wondering if we should have something like a CHANGELOG for
> >> > plasmate where we can put information about new functionality, and so
> >> > on. Is it possible ?
> >>
> >> Sure, just create a Changelog file on plasmate dir.
> >> So everybody got the svn access ? Diego, did you have any problems as it
> >> seems
> >> you're the only who did not commit anything yet ?
> >>
> >> Cheers,
> >>
> >> --
> >> Artur Duque de Souza
> >> OpenBossa Research Labs
> >> INdT - Instituto Nokia de Tecnologia
> >> --
> >> Blog: http://blog.morpheuz.cc
> >> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> >> --
> >
> >
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
> >
>
>
>
> --
> Shantanu Tushar(UTC +0530)
> http://www.shantanutushar.com
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: PlasMate && KDevplatform issue

[Diego Casella ([Po]lentino)]

Hi guys,
I'm  a bit in trouble with compiling kdevplatform module where the git
plugin is located.
In fact, compiling that module doesn't copy the include headers
from$HOME/kdevplatform/plugin/git folder
under $KDEDIR/include/kdevplatform/...
Same for the libraries, in the $KDEDIR/lib/kdevplatform there are only CMake
files.
I tried to modify by hand the CMakeLists.txt in git/ subfolder, without
results.
Any suggestion on how make it correctly installed ??
Have a look if the problem is present also in your pc, thanks =)

Diego.



> -- Messaggio inoltrato --
> From: "Artur Souza(MoRpHeUz)" 
> To: plasma-devel@kde.org
> Date: Mon, 22 Jun 2009 12:36:34 -0300
> Subject: Re: PlasMate previewer
> On Monday 22 June 2009, 11:57 Shantanu Tushar Jha wrote:
> > I was wondering if we should have something like a CHANGELOG for
> > plasmate where we can put information about new functionality, and so
> > on. Is it possible ?
>
> Sure, just create a Changelog file on plasmate dir.
> So everybody got the svn access ? Diego, did you have any problems as it
> seems
> you're the only who did not commit anything yet ?
>
> Cheers,
>
> --
> Artur Duque de Souza
> OpenBossa Research Labs
> INdT - Instituto Nokia de Tecnologia
> --
> Blog: http://blog.morpheuz.cc
> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> --
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Fwd: Some explanations/suggestion on plasmate

[Diego Casella ([Po]lentino)]

Got it !!
I'll try it s soon as I come home ( I'm @ university now! ).
C u at the meeting =)

cheers !


-- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: plasma-devel@kde.org
> Date: Thu, 11 Jun 2009 09:42:45 -0600
> Subject: Re: Fwd: Some explanations/suggestion on plasmate
> On Thursday 11 June 2009, Diego Casella ([Po]lentino) wrote:
> > I'm also planning to use the git plugin located in
> kdevplatform/plugins/git
> > instead of VNG, so I need to find a do about how to use it and add the
> > correct entries in CMakeLists.txt =)
>
> using the git plugin from kdevplatform makes a lot of sense, i think.
>
> for the CMakeLists.txt file, you will need to add this line:
>
>find_package(KDevPlatform 0.9.92 REQUIRED)
>
> to the include_directories, add ${KDEVPLATFORM_INCLUDE_DIR}
>
> to the link libraries, add ${KDEVPLATFORM_VCS_LIBRARY}
>
> that should get us building, anyways. :)
>
> then we can ditch the vng files (svn rm <-- there are few more satisfying
> commands sometimes ;) and start using the VCS libs from kdevplatform.
>
> --
> 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
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Fwd: Some explanations/suggestion on plasmate

[Diego Casella ([Po]lentino)]

Hi Shantanu,

recently I revised the sidebar code,splitted into four files to match the
convention "one file->one class" and extended it in order to implement an
horizontal sidebar, because I want to use it to manage the TimeLine class.
I'm also planning to use the git plugin located in kdevplatform/plugins/git
instead of VNG, so I need to find a do about how to use it and add the
correct entries in CMakeLists.txt =)
So, if any plasma developers can help me, I'll be happy !!

Cheers !


-- Messaggio inoltrato --
> From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Wed, 10 Jun 2009 23:29:22 +0530
> Subject: Re: Fwd: Some explanations/suggestion on plasmate
> I had recently added a kpart loading code to plasmate which, right now,
> enables loading an appropriate kpart when you select something on the edit
> tree view.
> I'm trying to figure out the things, finding out what to do next. So, just
> wanted kind of a status report on whats happening at your side, Diego, so
> that we can plan things out and distribute work further.
> Regards
>
> On Fri, May 29, 2009 at 1:58 AM, Aaron J. Seigo  wrote:
>
>> On Thursday 28 May 2009, Artur Souza(MoRpHeUz) wrote:
>> > > there is no such thing as a file in the Plasma::Package that isn't
>> part
>> > > of the Plasma::Package, so i don't think this would do anything other
>> > > than make another step that the user has to do and can get wrong (by
>> > > forgetting)
>> >
>> > I was thinking more in the way that the user just created a new graphic
>> in
>> > inkscape, saved it on the same folder as the project and wants to make
>> that
>> > file part of the project. If there is no "inotify" watching for new
>> files
>> > on the folder, there should be a way to add this new file to the
>> project...
>>
>> ah, right, so there are 3 ways to add a file to a project:
>>
>> * creating a new file in plasmate itself (create)
>> * adding a file from elsewhere in the file system (import)
>> * plopping a file into the package directory using some other program (mv
>> from
>> the command line, the gimp with an image, etc)
>>
>> create and import are easy and obvious: if the user selects "import" or
>> creates a new file for a type we don't have an editor part ... it opens a
>> file
>> dialog. otherwise create the file.
>>
>> there should be a KDirWatch on the Package root directory which takes care
>> of
>> the third case.
>>
>> --
>> 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
>>
>>
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
> --
> Shantanu Tushar(GMT +0530)
> http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma-devel Digest, Vol 11, Issue 78

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: "Aaron J. Seigo" 
> To: morph...@openbossa.org, plasma-devel@kde.org
> Date: Thu, 28 May 2009 14:28:19 -0600
> Subject: Re: Fwd: Some explanations/suggestion on plasmate
> On Thursday 28 May 2009, Artur Souza(MoRpHeUz) wrote:
> > > there is no such thing as a file in the Plasma::Package that isn't part
> > > of the Plasma::Package, so i don't think this would do anything other
> > > than make another step that the user has to do and can get wrong (by
> > > forgetting)
> >
> > I was thinking more in the way that the user just created a new graphic
> in
> > inkscape, saved it on the same folder as the project and wants to make
> that
> > file part of the project. If there is no "inotify" watching for new files
> > on the folder, there should be a way to add this new file to the
> project...
>
> ah, right, so there are 3 ways to add a file to a project:
>
> * creating a new file in plasmate itself (create)
> * adding a file from elsewhere in the file system (import)
> * plopping a file into the package directory using some other program (mv
> from
> the command line, the gimp with an image, etc)


An other idea I was thinking today is adding drag&drop capability to the
treeview dock widget..
So now we have an other way =)


> create and import are easy and obvious: if the user selects "import" or
> creates a new file for a type we don't have an editor part ... it opens a
> file
> dialog. otherwise create the file.
>
> there should be a KDirWatch on the Package root directory which takes care
> of
> the third case.
>
> --
> 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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Fwd: Some explanations/suggestion on plasmate

[Diego Casella ([Po]lentino)]

Well, I forwarded the message I sent today to morpeuz about some ideas on
plasmate.
Take a look, then tell me what you think about =)

-- Forwarded message --
From: Artur Souza(MoRpHeUz) 
Date: 2009/5/28
Subject: Re: Some explanations/suggestion on plasmate
To: "Diego Casella ([Po]lentino)" 


Hi Diego!

On Thursday 28 May 2009, 07:34 you wrote:
> a class declaration ). So, I was wondering if could I continue on riccardo
> code, adding all the basical function needed ( such as init,clone, pull,
> diff, apply, status, checkout and commit ).

Maybe it's a good idea to send an email do plasma-devel so others can also
give
their opinions on this one. I didn't take a look on Vng so I can't argue
here
very much. I'm just afraid that in the end we have to reimplement a lot of
things that are already in Vng

>1. run the git -add comand  every time a new file is created, and then
>run it every x minutes, defined by user from a form named "autosave",
> then run git -commit when the developer click on "save file" button. (
very
> ugly, I know )
>2. run git -add when the user press the "save file" button, and call
git
>-commit when "save project" is pressed, displaying a box for inserting
>informations on the commit. ( this makes more sense, but from the point
> of view of simplicity, there are too "save something" buttons )

Hmmm...another idea would be to have an "Add File To Project" like Kile and
other editors have. This way the "new files situation" is solved. Regarding
files
that are already being tracked, we should just add them all and then commit
when the auto save interval times out. If the user wants to put a message in
his commit, we can have a "Save With Description" option or something like
that...

But again, let's see what ideas people on plasma-devel have ;)

> A solution could be implementing the previewer as a tabbed widget, and put
> it together with the other  editor tabs, so the coder first edit all the
> files needed, then change to the preview tab to see the result =)
> Or, we can add an auto show/hide feature to the dock widget, so it pops-up
> only when needed.

The preview tab may work and I agree that maybe keeping the previewer open
all
the time may waste screen space...

Cheers! :)

---
Artur Duque de Souza
OpenBossa Research Labs
INdT - Instituto Nokia de Tecnologia
---
Blog: http://labs.morpheuz.eng.br/blog/
GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net
---


signature.asc
Description: PGP signature
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Plasmate development

[Diego Casella ([Po]lentino)]

Instead, my nick is [Po]lentino.
If I recall correctly, moofang will work on the previewer, me on Timeline
and GUI stuff, and you on the editor ( KParts, iirc =P ).
To be honest, I don't remember on which component the fourth guy is going to
work =P
Have a nice day,

Diego.

>-- Messaggio inoltrato --
>From: Yuen Hoe Lim 
>To: plasma-devel@kde.org
>Date: Sun, 3 May 2009 16:22:30 +0800
Hi Shantanu,
>
>My nick is moofang. Am putting it off atm until my big test next week
>is done >.<
>
>On 5/3/09, Shantanu Tushar Jha  wrote:
>> Hey, this is a mail to get/put an update on Plasmate. As I remember, we
had
>> distributed the work among 4 people including me, but unfortunately I
forgot
>> all of your nicks. So, please reply to this mail with them, and yes, I've
>> started looking into the editor part, noticed a Text Editor is already
>> implemented right now (not being shown though), will work on it.
>>
<> Cheers !
>>
>> --
>> Shantanu Tushar(GMT +0530)
>> http://www.shantanutushar.com
>>
>
>
>--
>
>Lim Yuen Hoe
>http://yuenhoe.co.cc/ 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: IRC Meeting for Plasmate (Yuen Hoe Lim)

[Diego Casella ([Po]lentino)]

 Fine for me =)
See you in IRC !

From: Shantanu Tushar Jha 
> To: plasma-devel@kde.org
> Date: Fri, 24 Apr 2009 20:23:16 +0530
> Subject: Re: IRC Meeting for Plasmate
> 1400 UTC fine for me. Hope it doesn't get earlier than that.
>
> On Fri, Apr 24, 2009 at 7:03 PM, Yuen Hoe Lim  wrote:
>
>> 14:00 UTC sounds good :) One or two hours later is also fine, but not
>> more please (it'd be past midnight where I am :)
>>
>> On 4/24/09, Artur Souza(MoRpHeUz)  wrote:
>> > Hi guys,
>> >
>> > As a lot of people want to work on Plasmate, Aaron suggested an irc
>> > meetinglet's make it real asap ? =)
>> >
>> > What about this Saturday, 14:00 UTC (or even later so aseigo can join) ?
>> >
>> > Cheers,
>> >
>> > --
>> > Artur Duque de Souza
>> > OpenBossa Research Labs
>> > INdT - Instituto Nokia de Tecnologia
>> > --
>> > Blog: http://labs.morpheuz.eng.br/blog/
>> > GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net
>> > --
>> >
>>
>>
>> --
>> 
>> Lim Yuen Hoe
>> http://yuenhoe.co.cc/
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>
>
>
> --
> Shantanu Tushar(GMT +0530)
> http://www.shantanutushar.com
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel