Re: [MeeGo-dev] File manager for Tablet Edition
On Friday, July 01, 2011 04:33:45 PM Éric Seigne wrote:
Le 01/07/2011 16:11, Martyn Russell a écrit :
When you connect a USB key you usually want to either copy data locally
or use data from USB key. In the former, I personally would prefer the
device to sync my data for me and in the later, use the data on the
USB key from applications.
and an other question: imagine people have a tablet and want make a
backup ... (for example on an usb key) ... what is the solution ?
You run your backup application, which requires a usb key or some
removable storage device. Logically, I wouldn't think of a file
manager as the place to start a backup, I would expect that in my list
of applications somewhere.
Okay,
so meego don't need a file manager for tablet, thanks a lot, i don't
waste my time.
Certainly forcing normal users to interact with a heirarchical file system like
Linux via file managers has been a proven failure, although 'power users' like
the people on this list have no trouble using file managers. But I don't think
we should be designing Meego for people like ourselves.
Plasma Active seems to have got the right idea to me. They are using the
Nepomuk store to have a common way for applications to store their data in a
non application specific way. Then they are using a metaphor of 'activities'
such as 'my photo stuff' or 'my social network stuff' to interact with the
environment as opposed to my '/home/myuser/Documents/something.mp3' which is
pretty low level. The average user doesn't want to see those paths like
'/home/myuser/Document', but they do want the activity of 'my music things' to
just find their mp3's wherever they are, and only show them in a context in
which they make sense.
Recently the Meego project seems to have been trying to de-emphasize Tracker,
which makes it harder for Tracker to be the glue between apps, like KDE
Nepomuk is in Plasma Active, as a basis for enabling activity functionality.
To me this seems a mistake. I recently watched a Steve Jobs video where he
said the meaning of 'focus' was being able to say 'no', and not saying 'yes'
all the time. In my opinion the Meego project needs to be able to focus and
know when it makes sense to say no. That should mean focusing on what the user
experience should be ('Activites'), and knowing when to say no to
functionaltiy which is part of that focus, like 'File Managers' and
'/home/myuser/Documents/something.mp3' being in the user's face.
-- Richard
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] File manager for Tablet Edition
On Friday, July 01, 2011 04:33:45 PM Éric Seigne wrote:
Le 01/07/2011 16:11, Martyn Russell a écrit :
When you connect a USB key you usually want to either copy data locally
or use data from USB key. In the former, I personally would prefer the
device to sync my data for me and in the later, use the data on the
USB key from applications.
and an other question: imagine people have a tablet and want make a
backup ... (for example on an usb key) ... what is the solution ?
You run your backup application, which requires a usb key or some
removable storage device. Logically, I wouldn't think of a file
manager as the place to start a backup, I would expect that in my list
of applications somewhere.
Okay,
so meego don't need a file manager for tablet, thanks a lot, i don't
waste my time.
Certainly forcing normal users to interact with a heirarchical file system like
Linux via file managers has been a proven failure, although 'power users' like
the people on this list have no trouble using file managers. But I don't think
we should be designing Meego for people like ourselves.
Plasma Active seems to have got the right idea to me. They are using the
Nepomuk store to have a common way for applications to store their data in a
non application specific way. Then they are using a metaphor of 'activities'
such as 'my photo stuff' or 'my social network stuff' to interact with the
environment as opposed to my '/home/myuser/Documents/something.mp3' which is
pretty low level. The average user doesn't want to see those paths like
'/home/myuser/Document', but they do want the activity of 'my music things' to
just find their mp3's wherever they are, and only show them in a context in
which they make sense.
Recently the Meego project seems to have been trying to de-emphasize Tracker,
which makes it harder for Tracker to be the glue between apps, like KDE
Nepomuk is in Plasma Active, as a basis for enabling activity functionality.
To me this seems a mistake. I recently watched a Steve Jobs video where he
said the meaning of 'focus' was being able to say 'no', and not saying 'yes'
all the time. In my opinion the Meego project needs to be able to focus and
know when it makes sense to say no. That should mean focusing on what the user
experience should be ('Activites'), and knowing when to say no to
functionaltiy which is part of that focus, like 'File Managers' and
'/home/myuser/Documents/something.mp3' being in the user's face.
-- Richard
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] File manager for Tablet Edition
On Friday, July 01, 2011 09:52:02 PM you wrote:
From: Richard Dale richard.d...@telefonica.net
To: meego-dev@meego.com
Sent: Friday, July 1, 2011 3:30 PM
Subject: Re: [MeeGo-dev] File manager for Tablet Edition
On Friday, July 01, 2011 04:33:45 PM Éric Seigne wrote:
Le 01/07/2011 16:11, Martyn Russell a écrit :
When you connect a USB key you usually want to either copy data
locally or use data from USB key. In the former, I personally would
prefer the device to sync my data for me and in the later, use the
data on the USB key from applications.
and an other question: imagine people have a tablet and want make a
backup ... (for example on an usb key) ... what is the solution ?
You run your backup application, which requires a usb key or some
removable storage device. Logically, I wouldn't think of a file
manager as the place to start a backup, I would expect that in my list
of applications somewhere.
Okay,
so meego don't need a file manager for tablet, thanks a lot, i don't
waste my time.
Certainly forcing normal users to interact with a heirarchical file system
like Linux via file managers has been a proven failure, although 'power
users' like the people on this list have no trouble using file managers.
But I don't think we should be designing Meego for people like ourselves.
Plasma Active seems to have got the right idea to me. They are using the
Nepomuk store to have a common way for applications to store their data in
a non application specific way. Then they are using a metaphor of
'activities' such as 'my photo stuff' or 'my social network stuff' to
interact with the environment as opposed to my
'/home/myuser/Documents/something.mp3' which is pretty low level. The
average user doesn't want to see those paths like
'/home/myuser/Document', but they do want the activity of 'my music
things' to just find their mp3's wherever they are, and only show them in
a context in which they make sense.
Recently the Meego project seems to have been trying to de-emphasize
Tracker, which makes it harder for Tracker to be the glue between apps,
like KDE Nepomuk is in Plasma Active, as a basis for enabling activity
functionality. To me this seems a mistake. I recently watched a Steve
Jobs video where he said the meaning of 'focus' was being able to say
'no', and not saying 'yes' all the time. In my opinion the Meego project
needs to be able to focus and know when it makes sense to say no. That
should mean focusing on what the user experience should be ('Activites'),
and knowing when to say no to functionaltiy which is part of that focus,
like 'File Managers' and '/home/myuser/Documents/something.mp3' being in
the user's face.
I don't think accommodating average/new users vs power users needs to be
mutually exclusive or burdensome. Provide a contextual approach by
default, with a powerful traditional file manager under the hood.
I think that would be an example of what Steve Jobs would call 'lack of
focus'. The failure to say 'no' when it makes sense.
I also think the fact that iOS have just dropped letting the users see the file
system without coming up with a compelling alternative like KDE Nepomuk
Activities or something similar with Tracker is one of their biggest competive
weaknesses.
-- Richard
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions - QSparql
On Saturday, March 26, 2011 01:34:19 PM Ville M. Vainio wrote: On Sat, Mar 26, 2011 at 3:20 PM, Patrick Ohly patrick.o...@intel.com wrote: To give just one example, who is the owner of a QSparqlResult? This example here has an explicit delete: http://maemo.gitorious.org/maemo-af/qsparql/blobs/master/examples/sparql/ asynctracker/main.cpp This one doesn't: http://maemo.gitorious.org/maemo-af/qsparql/blobs/master/examples/sparql/ simple/main.cpp These questions (and memory leak?) could be avoided if QSparqlResult wasn't a plain pointer. Without taking a stance on how modern this approach is, it's something that's familiar to Qt developers from http://doc.qt.nokia.com/4.7-snapshot/qnetworkaccessmanager.html#get QSparqlResult is a QObject, and its QObject parent is the QSparqlConnection that created it. You can either delete a QSparqlResult yourself, or you can leave it to the QSparqlConnection to delete the results it owns, from its destructor. If a QSparqlResult is still active when an owner QSparqlConnection is deleted you will get a warning message. That is exactly the same as the example given above where a QNetworkAccessManager owns QNetworkReplies and deletes them in its destructor. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 09:11:48 AM Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Well Tracker is in MeeGo sure, but I was talking about RAD environments on top of Tracker, and in one of the mails on this architecture thread I saw this: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 09:11:48 AM Ville M. Vainio wrote: On Thu, Mar 24, 2011 at 10:16 PM, Richard Dale richard.d...@telefonica.net wrote: I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely Agreed. Luckily tracker will still be there on the platform (as Marius stated earlier in this thread), so it can be used by willing applications. It's just that contact information is not *primarily* stored there anymore - but we can arrange for an (unofficial) way where it gets moved there from EDS anyway. Yes Tracker is still part of MeeGo, but I was talking specifically about RAD environments built on top of Tracker. My concern is that I saw this statement in one of the mails in this thread: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the official way of using Tracker in Maemo Qt based code. As far as I know it has been packaged for MeeGo too, and I am not sure if the above statement from Arjan van de Ven is correct. In order to build the RAD environment, that I personally dream of, QSparql will be needed even if application programmers won't all use it directly. Maybe we can do a visual QtCreator environment via QSparql QML integration and QtCreator plugins, to allow app developers to rapidly create mashups with the application independent data in Tracker. That data might by combined with data from SPARQL endpoints out on the web that is also retrieved via QSparql. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Friday, March 25, 2011 03:01:43 PM Ville M. Vainio wrote: On Fri, Mar 25, 2011 at 4:53 PM, Richard Dale richard.d...@telefonica.net wrote: On Monday, March 07, 2011 10:06:08 PM Arjan van de Ven wrote: Are you planning to support or implement a QSparql backend for EDS? I suspect we'll never see QSparql in MeeGo the way things are going Disclaimer: I am a QSparql developer QSparql is the standard way of accessing Tracker from Maemo in Qt code, and as far as I know it has been packaged for MeeGo too. In order to build the Qt based RAD environment, that I personally dream of, QSparql will be needed. Is there a particular reason not to have QSparql, when you already have Tracker? I wouldn't have thought there was, but obviously the statement above from Arjan van de Ven concerned me. (Someone should really summarize these threads in a wiki) Maybe it shouldn't be used directly by application programmers, but it will be needed as a base for building visual development tools that might use QML with QtCreator plugins support. Perhaps you can elaborate on this RAD tools elsewhere, say, meego-community mailing list? I have hard time thinking how a RAD tool for sparql would look like, but the thought is intriguing... Well, RDF stores are just databases that happen to be more general and based on graphs, rather than being based on tables like relational databases. Often you can view RDF data as a table and that works fine. But I don't see any reason why visual development tools for RDF/SPARQL stores should look much different to what people are familiar with from tools like Visual Basic. Or ORM's like NeXT/Apple's Enterprise Object Framework, or the Core Data modern equivalent, that are combined with Interface Builder for visually composing UIs. -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
On Thursday, March 24, 2011 06:20:52 PM zoltan@nokia.com wrote: Hi Carsten, From: carsten.m...@gmail.com [mailto:carsten.m...@gmail.com Sent: 24 March, 2011 09:08 Please also remember that if there is supposed to be a technology selection, your dispute document also has to list people/companies publically committed to the task of implementation/maintenance. Actual contribution/commitment weighs harder than numbers sometimes. Both solutions have people committed to it. It's pretty obvious Intel has knowledge assets and people doing SyncEvolution/EDS already so they would probably not be interested in investing in the alternative. Which means someone else has to do the lifting. We can't ask for Intel's investment into technologies or strong arm them, nor should we. True, and at the moment they can't rely on Nokia. But Nokia does not control tracker either, most of the tracker guys are external consultants. If I was a product manager or TSG looking at the technology choice/selection I would look, even before looking at the numbers, check if there's actual resources listed that will actually do the hard lifting for technology direction and discard the technologies that doesn't have sufficient. And then evaluate based on the facts. There are two things: 1. For short term, doing the homework: MeeGo needs to maturize as fast as possible, and we need to get the releases rolling with usable content. 2. MeeGo needs to be competitive on the long term, even become the leading innovation platform of the future. Your comment and Intel's decision addressed the first part. But there is a lot of competition out there, which is pulling away on the integrated content handling technologies that e.g. tracker tries to cover (Android by big margin, and I surmise WP7 might have something too), so there should be a long term technology selection plan, too. Very well put. We have to be 10x better than the competition otherwise we are going nowhere. In my opinion adding another 'data silo' for contacts in the way switching to using EDS would do, is no better than being 1x the competion although it might be the less risky option in the short term. I personally think that the Nepomuk non-application specific integrated data approach could be a killer feature of MeeGo. In comparison iOS is completely broken with respect to sharing data between applications. As far as I know, each application is expected to have its own way of storing data and there are obvious real problems with that simplistic way of hiding the Unix file system from users. I don't get the impression that Android is much better. If we are comparing Tracker with EDS we are not comparing like with like. The problem is that we haven't got as far as implementing elegant RAD tools that allow applications to make use of the linked cross-application data in Tracker. Nor have we got as far as making use of the fact that local RDF data can be combined with data stores out on the web. For instance, you may have some music album with metadata stored in Tracker and might like to make a query to web based SPARQL endpoints such as DBpedia for further info. The RDF linked data approach allows ontologies to be linked via mechanisms such as 'SKOS' (in SQL terms I would describe that as a way of making one database schema map onto another). That way we can link local personal Nepomuk data with web based RDF resources, such as FOAF or whatever, that are out on the web of linked data. We are talking revolution here, and certainly Intel might not have the resources to make that happen in-house, but why should that slow down the community based MeeGo project? -- Richard ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
