Hi David,
I have come to understand that QtCreator is
maintaining a local MIME database that is completely independent from the
system MIME database, and is built from scratch from XML files that are
part of the QtCreator distribution.
Yes but it doesn't have to stay that way!
It
Hi David,
It took me a while but I have a code base now for QtCreator that keeps
all previous functionality.
For that I separated the MIME type handling code in QtCreator in the
stuff that is also in qmime and the application-specific code that
needs to run on top of that. The
Hi Иван,
The consensus on the list seemed to be that we want
- to have a clean and minimalistic public API
- to not support editing / user MIME type use cases
This is your consensus, not mine.
My understanding is that user-defined MIME types are for supporting editing
MIME types.
Hi David,
On Monday 26 September 2011 15:46:12 ext Иван Комиссаров wrote:
In other news, I pushed the code for faster and more accurate glob
matching (currently in the 'david' branch).
Please, merge your changes to master, if Michael agreed.
please do so.
Thanks
Michael
Hi Иван,
I will merge changes to master.
perfect, I just received the changes.
I will start to work on changes for QtCreator in my branch. Actually,
Creator depends on user mime-types and we can't use qmime in QtCreator
without this feature.
Is there something I can help you with?
Michael
Hi David,
Иван and I have agreed on a codebase on qmime.git. It pretty much matches what
was discussed on the mailing list. I will merge missing features from my
qtaddonmimetype.git repostiory like QML wrappers into qmime.git.
You were offering to implement the shared-mime-info backend. If
On Wednesday 21 September 2011 19:09:11 ext Thiago Macieira wrote:
Is it really nessecairy that _everyone_ has public access to the signal?
What if only QObject had access to it? Would that work? If so, it could
work to just make QObject a friend class of every class that has the
Q_OBJECT
Hi David,
On Wednesday 21 September 2011 08:27:52 ext David Faure wrote:
Well, apart from the too many details about the spec the API in
qmime.git is mostly good, I like QMimeDatabase.
But the code is mostly about parsing XML files...
Well, anyway. I'll let you and
On Wednesday 21 September 2011 15:19:59 ext Иван Комиссаров wrote:
I explored native mime database in Windows. It is stored in registry and
contains data for most common extensions. It is a map from *.extension
to mime type name. This mime type name is equal to freedesktop.org,
however for
On Thursday 15 September 2011 11:45:30 ext Thiago Macieira wrote:
Why can't you think of MIME type editor, e.g. like one in ROX Filer?
And the question is whether this is a usecase that should be supported by
Qt essentials. I don't think so.
Mimetype handling should become part of
On Thursday 15 September 2011 09:50:02 ext David Faure wrote:
Also, it exposes too much internals of the spec, such as the various fields
for magic (content-based) matching; this is all because QtCreator has a GUI
for defining your own mimetypes, but I can't think of any use case for a
user
On Monday 19 September 2011 12:04:01 ext Robin Burchell wrote:
In the spirit of this discussion I'd like to point out that I need a way
to create QMimeType objects with all their properties set. Can we add
constructors to QMimeTypeData and QMimeType like this:
why do you need this done in
On Monday 19 September 2011 12:39:20 ext Иван Комиссаров wrote:
In the spirit of this discussion I'd like to point out that I need a
way to create QMimeType objects with all their properties set. Can we
add constructors to QMimeTypeData and QMimeType like this:
why do you need
So, we also have open question about storing mime types under mac/win -
user won't copy million text/xml files to deploy his program.
There is just one xml file to copy. The rest is generated by update-mime-
database. But I can see that given Windows's non-existing dependency
handling,
Hi David or Иван,
Could you please review and apply the patch for qmime that I attached? It
corrects the documentation to the new naming scheme.
Thanks
Michael
diff --git a/src/magicmatcher.cpp b/src/magicmatcher.cpp
index 7996b03..5588225 100644
--- a/src/magicmatcher.cpp
+++
On Thursday 15 September 2011 09:50:02 ext David Faure wrote:
As Wolf-Michael noted, the API for creating mimetypes doesn't really belong
in there; that's far too system-dependent, and far too rare compared to
queries.
If there are no objections then I will go ahead and remove
-
On Thursday 15 September 2011 10:55:41 ext David Faure wrote:
On the other hand I'm not sure that querying the association with
applications and the open/view/edit distinction belongs there, it
doesn't
seem very cross- platform -- but that's a separate discussion.
Similar to KDE,
17 matches
Mail list logo
