On 02/25/2017 12:08 PM, David Faure wrote:
>>> Also, the Manage MIDI Banks and Programs window is larger. On my 768
>>> vertical display, I can't see the Options section in the lower right.
>>> In 16.06 the entire dialog fits on my screen.
> This dialog should be OK now.
It's better, but still
On 03/01/2017 03:25 AM, David Faure wrote:
> Done.
>
> --hacks;
I tested several different scenarios, and this problem is throughly solved.
I should get time tomorrow to finish that bit of file dialog hackery,
and then I think this is stable enough to release.
--
D. Michael McIntyre
On mercredi 1 mars 2017 06:31:15 CET D. Michael McIntyre wrote:
> I'm comfortable with ignoring the past on this one and worrying about
> dealing with any present and future consequences.
Done.
--hacks;
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
--
On 02/28/2017 07:41 PM, Ted Felix wrote:
>That was so long ago We've restructured a lot of stuff in the
> meantime and it's entirely possible that it's safe to do away with it.
It is entirely possible. You've made a lot of progress in that area.
>I'll take a peek at the mailing lis
> r11067
> Author: cannam
> Date: Tue Oct 20 11:38:30 2009 +
>
> * Fix a further crash on document load. This is probably the crash that
> has been troubling Emanuel.
The closest thing I can find in the mailing list was on Oct 8 2009.
Emanuel reported a crash when opening an r
On 02/28/2017 07:08 PM, David Faure wrote:
> I vote for killing all this blockSignals(true) usage,
I second this. I've been removing every blockSignals() that I come
across. So, if you can get rid of it, please do.
> but the question is what
> happens then. In my quick test (start with cmdl
On mercredi 1 mars 2017 01:08:55 CET David Faure wrote:
> presumably it was added for a reason?
OK, git log being much more convenient than svn to figure this out I had a
quick look, and here's the commit that introduced it:
r11067
Author: cannam
Date: Tue Oct 20 11:38:30 2009 +
* Fix
On lundi 27 février 2017 13:19:16 CET David Faure wrote:
> On lundi 27 février 2017 13:09:11 CET Ted Felix wrote:
> > On 02/26/2017 11:28 PM, D. Michael McIntyre wrote:
> > > Load a document, and dozens of things break instantly. This is
> > > infinitely repeatable here. (Only testing with Qt5 bu
On 02/27/2017 07:19 AM, David Faure wrote:
> No need to bisect, it's clear that this is related to my redesign of the
> parameter area (was a (useless) stack widget inside a dockwidget,
> now it's a simple widget in a layout, the only thing I kept was that it's a
> scrollarea). I didn't think of t
On 02/26/2017 11:28 PM, D. Michael McIntyre wrote:
> Load a document, and dozens of things break instantly. This is
> infinitely repeatable here. (Only testing with Qt5 builds here.)
OK, since it seemed like a recent problem, I did a quick test of
r14965 which is just prior to the new style
On lundi 27 février 2017 13:09:11 CET Ted Felix wrote:
> On 02/26/2017 11:28 PM, D. Michael McIntyre wrote:
> > Load a document, and dozens of things break instantly. This is
> > infinitely repeatable here. (Only testing with Qt5 builds here.)
>
>Ah ha! That's it. I'm seeing this with Qt4
On 02/26/2017 11:28 PM, D. Michael McIntyre wrote:
> Load a document, and dozens of things break instantly. This is
> infinitely repeatable here. (Only testing with Qt5 builds here.)
Ah ha! That's it. I'm seeing this with Qt4 too. Should be easy to
bisect and find. I'll take a look somet
On 02/26/2017 10:07 PM, Ted Felix wrote:
>This sounds really familiar.
>
>Deleting the build directory and rebuilding fixed it for me.
>
>It would be nice to know why, though.
Nope. I reverted to the factory autoload and repeated my tests. The
document loaded at startup works fine
On 02/26/2017 06:26 PM, David Faure wrote:
> Very strange (cmake never requires a clean build, in theory), but I'm
> reassured that it's not all catastrophic :-)
Starting Rosegarden with ./rosegarden is different from starting with a
file on the command line, or loading a file through the GUI at
On 02/26/2017 09:56 PM, D. Michael McIntyre wrote:
> Correction. I'm using the same build now, and the parameter area
> scrollbar is not functioning. The collapsing frames are not
> functioning. The IPB plugin buttons are not functioning.
This sounds really familiar.
Deleting the build d
On 02/26/2017 05:48 PM, D. Michael McIntyre wrote:
> I did a totally clean build from scratch, and it solved the lion's share
> of problems I intended to work through today.
Correction. I'm using the same build now, and the parameter area
scrollbar is not functioning. The collapsing frames are
On dimanche 26 février 2017 23:48:32 CET D. Michael McIntyre wrote:
> On 02/26/2017 04:18 PM, D. Michael McIntyre wrote:
> > I'm going to just jump in and see what I can do before enumerating
> > everything. I have some free time today, believe it or not!
>
> While hunting down a problem, I saw s
On 02/26/2017 04:18 PM, D. Michael McIntyre wrote:
> I'm going to just jump in and see what I can do before enumerating
> everything. I have some free time today, believe it or not!
While hunting down a problem, I saw some really weird behavior. I
changed one line of code to make an element st
I finally got up to date with the latest changes. I tried using
Rosegarden to import a MIDI file and play it, and I've run into all
kinds of catastrophic show-stopping problems, and even more minor
glitchy ones are popping out at me.
I'm going to just jump in and see what I can do before enume
On vendredi 24 février 2017 12:26:05 CET David Faure wrote:
> > The Manage MIDI Banks and Programs window (press the Banks... button
> > in the Manage MIDI Devices window) (BankEditorDialog): Select a bank.
> > On the right, the labels appear to be light gray on slightly darker
> > gray. The labe
On 02/24/2017 09:14 AM, David Faure wrote:
> Yes I did that search of course, I was just hoping to get some help with
> those, but yes, at least giving me instructions for how to reach these dark
> corners of the application could be useful ;)
I had hoped to get my hands into this long before now
On vendredi 24 février 2017 14:30:37 CET Ted Felix wrote:
>Latest stuff looks good.
>
>I searched the remaining .ui file and it looks like there's no more
> stylesheets hiding there.
>
>What about a search on setStyleSheet()? There seem to be 15 or so of
> these scattered in obscure
Latest stuff looks good.
I searched the remaining .ui file and it looks like there's no more
stylesheets hiding there.
What about a search on setStyleSheet()? There seem to be 15 or so of
these scattered in obscure places. Would it be helpful if I tracked
down each of these test cas
On mercredi 22 février 2017 02:17:24 CET Ted Felix wrote:
>Ok, a few more issues. Again, this is Qt4/GNOME/Unity/Ubuntu.
>
>The pane on the left with the Segment Parameters, Track Parameters,
> etc... (RosegardenParameterArea): The scrollbar doesn't work. You'll
> likely need to shrink
On 02/22/2017 08:51 AM, Ted Felix wrote:
>>The pane on the left with the Segment Parameters, Track Parameters,
>> etc... (RosegardenParameterArea): The scrollbar doesn't work. You'll
>> likely need to shrink the window vertically to get the scrollbar
>> depending on your display resolution.
On 02/21/2017 08:17 PM, Ted Felix wrote:
>Ok, a few more issues. Again, this is Qt4/GNOME/Unity/Ubuntu.
I've just retested in Qt5 with the following results...
>The pane on the left with the Segment Parameters, Track Parameters,
> etc... (RosegardenParameterArea): The scrollbar does
On 02/21/2017 08:17 PM, Ted Felix wrote:
>Ok, a few more issues. Again, this is Qt4/GNOME/Unity/Ubuntu.
When I get a chance, I want to see how much of this happens in Qt5
builds. Maybe it's time to drop support for Qt4 builds. I'm not aware
of any other project of significance that suppo
Ok, a few more issues. Again, this is Qt4/GNOME/Unity/Ubuntu.
The pane on the left with the Segment Parameters, Track Parameters,
etc... (RosegardenParameterArea): The scrollbar doesn't work. You'll
likely need to shrink the window vertically to get the scrollbar
depending on your dis
On 02/18/2017 07:02 PM, David Faure wrote:
> I committed some fixes for the statusbar now, please check, since I wasn't
> seeing that white frame (but a black one).
Looks good. No frames at all now.
>>Also, for me (Qt4/GNOME/Unity/Ubuntu), all the tooltips are blank.
> Indeed, there was a
On 02/18/2017 07:03 PM, David Faure wrote:
> Sorry, *that* I can't fix -- other than recommending to use krita :-)
I do use Krita, but Krita != GIMP.
--
D. Michael McIntyre
--
Check out the vibrant tech community on on
On samedi 18 février 2017 06:07:27 CET D. Michael McIntyre wrote:
> I have the same problem with GTK applications on my distro's current
> KDE. All the tooltips are blank like that, which makes the GIMP
> challenging to use.
Sorry, *that* I can't fix -- other than recommending to use krita :-)
-
On samedi 18 février 2017 02:05:59 CET Ted Felix wrote:
> >> and the progress bar
> >
> > Could it be that you didn't have r14974 from yesterday evening, yet?
>
>Nope. White outlines are still there. See attached
> rg-lower-right.png. With the older version, it looks like it's supposed
> t
On 02/17/2017 08:05 PM, Ted Felix wrote:
> Nope. White outlines are still there. See attached
> rg-lower-right.png. With the older version, it looks like it's supposed
> to be 3D. The upper left is black (invisible) and the lower right is
> white.
That wasn't "supposed to be" that was just
On 02/06/2017 04:10 AM, David Faure wrote:
Ah! So the CSS selectors did apply to the transport dialog, removing the space
from the object name. Fixed now, the transport dialog looks like before.
Looks good.
and the progress bar
Could it be that you didn't have r14974 from yesterday evening
On lundi 6 février 2017 11:56:49 CET D. Michael McIntyre wrote:
> I get a Qt file dialog that uses generic icons, and the only part of it
> that's themed is the horizontal scrollbar
OK, I fixed the unwanted theming of the scrollbars in r14978.
--
David Faure, fa...@kde.org, http://www.davidfaure
On 02/06/2017 04:10 AM, David Faure wrote:
> Yeah, I have been fighting with dock widgets quite a lot. Before I invest more
> time into it, does that thing really need to be a dock widget? It doesn't seem
> useful to move it to another position (top, right...) nor to make it float
> outside the ma
On lundi 6 février 2017 01:12:21 CET Ted Felix wrote:
> On 02/05/2017 03:50 PM, David Faure wrote:
> > Please report any styling regressions to me, I tested all widgets, but not
> > in all circumstances (e.g. I didn't open all dialogs and all windows).
> >
> > The Qt4 version builds, but I tested
On 02/05/2017 03:50 PM, David Faure wrote:
Please report any styling regressions to me, I tested all widgets, but not in
all circumstances (e.g. I didn't open all dialogs and all windows).
The Qt4 version builds, but I tested it even less.
Some white/gray frames have appeared in Qt4 under Ub
On lundi 23 janvier 2017 10:01:45 CET David Faure wrote:
> The longest part of the job is obviously to convert the stylesheet to a
> QStyle subclass, but I'm making good progress with that (well... I'm at 27%
> of the qss file ;).
All done, the stylesheet is gone, and the custom QStyle replaces it
On dimanche 15 janvier 2017 10:31:27 CET David Faure wrote:
> Feel free to experiment meanwhile and tell me what you find
OK, I did experiments (and reading Qt source code) and here are the results.
* setStyleSheet() on a widget always propagates to child widgets
* there is no way to prevent it
On dimanche 15 janvier 2017 00:44:01 CET D. Michael McIntyre wrote:
> > OK the most important part is here (/usr/share) but I really wonder what's
> > in your /usr/share/xsessions/plasma (for my curiosity, can you do a
> > `find` there, to show me?)
>
> There is no /usr/share/xsessions/plasma.
OK
On 01/14/2017 04:41 AM, David Faure wrote:
> A *.rg file should yield application/x-rosegarden-composition,
> Do you have a /usr/share/mime/packages/rosegarden.xml file?
That was a helpful clue. Thanks!
I never changed the prefix, and our version of rosegarden.xml got
installed in /usr/local,
On mercredi 11 janvier 2017 21:36:23 CET D. Michael McIntyre wrote:
> On 01/10/2017 04:15 AM, David Faure wrote:
> > Step 1 can be tested separately with "kmimetypefinder5 myfile".
>
> Yields "audio/x-rosegarden" as expected.
For which type of file?
A *.rg file should yield application/x-rosegard
On 01/10/2017 04:15 AM, David Faure wrote:
> Step 1 can be tested separately with "kmimetypefinder5 myfile".
Yields "audio/x-rosegarden" as expected.
> What's your setup? Is XDG_DATA_DIRS set to a special value?
I found some irregularities in that string. I failed to determine what
got them t
On 01/09/2017 03:33 PM, David Faure wrote:
> Anything I can help with? What's the actual bug?
MIME type icons aren't working in KDE file dialogs again, or in Dolphin.
I JUST fixed that within the last six months, and it's already broken
again.
Our in-house Qt file dialogs have no icons for a
On 01/09/2017 01:11 PM, D. Michael McIntyre wrote:
> All my more important responsibilities are under snow today, so I got a
> chance to try cleaning up the file dialogs that are horrible with the
> Qt5/KDE5 interaction.
>
> Long story short, I came, I saw, I fiddled, I gave up in disgust.
For some
On lundi 9 janvier 2017 15:11:14 CET D. Michael McIntyre wrote:
> All my more important responsibilities are under snow today, so I got a
> chance to try cleaning up the file dialogs that are horrible with the
> Qt5/KDE5 interaction.
>
> Long story short, I came, I saw, I fiddled, I gave up in dis
On 11/13/2015 03:59 PM, David Faure wrote:
> Qt5 support added (patch updated). But the code isn't fully ready for Qt5,
> I guess the Qt5 port hasn't been merged yet?
The status of the Qt5 port is in patch #53:
https://sourceforge.net/p/rosegarden/patches/53/
"As of [r13745], all Qt5 code
On 07/01/2014 05:22 AM, Tim Munro wrote:
> The problem involves background colors in the tool bars
> (data/rosegarden.qss). Linear gradients were partially broken in qt4, so
> the gradient direction that didn't work had been replaced with a pixmap.
> Neither direction seems to work in qt5, so bot
On 06/30/2014 10:01 AM, D. Michael McIntyre wrote:
> On 06/30/2014 12:03 PM, Richard Bown wrote:
>
>> So what is wrong with them?
>
> They're all black, unless they're activated. I've run into this kind of
> problem a lot. I'm sure I could fix it one way or another.
>
The problem involves backg
On Mon, Jun 30, 2014 at 7:01 PM, D. Michael McIntyre <
rosegarden.trumpe...@gmail.com> wrote:
> On 06/30/2014 12:03 PM, Richard Bown wrote:
>
> So what is wrong with them?
>>
>
> They're all black, unless they're activated. I've run into this kind of
> problem a lot. I'm sure I could fix it one
On 06/30/2014 12:03 PM, Richard Bown wrote:
> So what is wrong with them?
They're all black, unless they're activated. I've run into this kind of
problem a lot. I'm sure I could fix it one way or another.
--
D. Michael McIntyre
On 30 Jun 2014, at 13:17, D. Michael McIntyre
wrote:
> The only thing jumping out at me that's SERIOUSLY wrong is the icons in
> the notation editor.
So what is wrong with them?
I’ll probably not spend that much more time on this ‘release’ (it being an
alpha ad-hoc thing still) and will pack
On 06/27/2014 09:07 AM, Richard Bown wrote:
> a bit nasty though perhaps because it has no style now - so I might
> change defaults to non-thorn. This is how it runs up as default currently:
The only thing jumping out at me that's SERIOUSLY wrong is the icons in
the notation editor. Every incr
On Thu, Jun 26, 2014 at 11:56 AM, Richard Bown <
richard.b...@ferventsoftware.com> wrote:
> dependencies to shake out
>
Well it builds and runs up now and I'm doing some testing and reintroducing
some necessary platform specific tweaks. Default theme is a bit nasty
though perhaps because it has n
On Wed, Jun 25, 2014 at 3:08 PM, Richard Bown <
richard.b...@ferventsoftware.com> wrote:
> which is the cause of some of this.
>
Well, its built but I'm having a time trying to get the 32/64 bit
dependencies to shake out on Windows 8.1. Dependency walker is showing a
mixture of 32 and 64 bit l
On 06/25/2014 08:42 AM, Richard Bown wrote:
> Saying that nicely teased out a few of course. One I can't get my head
> around is this in editors/segment/compositionview/CompositionItemImpl.h
>
> class CompositionItemImpl : public _CompositionItem {
>
> C:\rosegarden-for-windows\RosegardenW\gui\edi
On Wed, Jun 25, 2014 at 3:05 PM, Ted Felix wrote:
>
> I've simplified and rewritten quite a bit of stuff in this area. Neither
> of those names exist anymore in current rg.
Yes I thought as much actually after reviewing what's in SVN. I'm using an
old .pro file from the last time I built it w
On Wed, Jun 25, 2014 at 1:48 PM, Richard Bown <
richard.b...@ferventsoftware.com> wrote:
> nothing else so far too alarming
>
Saying that nicely teased out a few of course. One I can't get my head
around is this in editors/segment/compositionview/CompositionItemImpl.h
class CompositionItemImpl
On 06/25/2014 07:48 AM, Richard Bown wrote:
> of judicious commenting. Which way are you guys thinking of going
> regarding the QStyle and Fusion style etc? I'm not sure Style
> subclassing is the way forward with Qt5?
I'm thinking let's do whatever it takes to hack around that problem for
now
On Tue, Jun 17, 2014 at 1:19 PM, Ted Felix wrote:
> It is partially complete in trunk.
>
I'm about half way through getting the GUI built on Qt5.3.1 with a bit of
judicious commenting. Which way are you guys thinking of going regarding
the QStyle and Fusion style etc? I'm not sure Style subcla
On 06/11/2014 04:44 PM, Ted Felix wrote:
>
> I've committed the setRawHeader() fix for the .rg file decompression
> issue. However, I was unable to test as my server doesn't exhibit the
> "Content-Encoding: gzip" behavior.
>
> Tim, can you test the latest svn to see if it is leaving .rg fi
On 06/17/2014 05:43 AM, Richard Bown wrote:
> Is the qt5 merge still in progress? Is there a branch for it and how
> recent was that taken?
Status of Qt5 is in patch #53:
http://sourceforge.net/p/rosegarden/patches/53/
It is partially complete in trunk. Just needs someone to review and
On 06/11/2014 04:44 PM, Ted Felix wrote:
> On 05/23/2014 04:36 AM, Tim Munro wrote:
>> As far as I know the server itself has nothing to do with the
>> unzipping process. It seems to be something that Qt is doing on its
>> own when the (redundant) raw header is not added.
>
> I've committed th
On 05/23/2014 04:36 AM, Tim Munro wrote:
> As far as I know the server itself has nothing to do with the
> unzipping process. It seems to be something that Qt is doing on its
> own when the (redundant) raw header is not added.
I've committed the setRawHeader() fix for the .rg file decompressio
On 05/23/2014 01:36 AM, Tim Munro wrote:
> I've attached the stand-alone Qt testbed that I used to play with this
> stuff. You might find it useful.
Ted,
Forgot to mention that there are two HTTP methods in this thing. The
one you would interested in is found in "HttpAlt.cpp."
Tim Munro
---
On 05/22/2014 04:16 AM, Ted Felix wrote:
I get it now. Ok, I'll do some testing and see if my server
reproduces the problem. Then I'll add that and see if I can come up
with some further test cases to make sure it's working with all file
types. E.g. importing a MIDI file would be good, if
On 05/22/2014 03:58 AM, Tim Munro wrote:
> NetworkAccessManager already automatically provides the header
> "Accept-Encoding: gzip, deflate," so adding
> QNetworkRequest::setRawHeader("Accept-Encoding", "gzip, deflate") to
> the code in no way changes what the server sees.
>
> It does, however, see
On 05/21/2014 09:29 AM, Ted Felix wrote:
> Tim and Tom, what's the final decision here? Should we add this?
>
> QNetworkRequest::setRawHeader("Accept-Encoding", "gzip, deflate");
>
> ...or are we ok without it? Tim seemed to indicate that this was
> already happening within Qt.
>
> Just w
> On 05/17/2014 12:54 PM, Tom Breton (Tehom) wrote:
>>> It would seem supplying any sort of
>>> Accept-Encoding header is adequate to prevent QNetworkAccessManager
>>> from doing its thing, but I have no way of verifying this in all
>>> cases.
>> That does seem to be it. In this QT bug report,
>>
On 05/21/2014 06:07 PM, Ted Felix wrote:
> Unfortunately, no, we can't build against Qt5 just yet. I've only
> got the "worst" patch done, and a handful of the ones that I was able to
> easily understand. I'm keeping track of which have been applied in the
> patch tracker. I'm pretty much d
On 05/21/2014 04:55 PM, D. Michael McIntyre wrote:
> Am I reading everything correctly, and it should be possible to build
> with either Qt 4 or Qt 5 now? I attempted to build with Qt 5, and I'm
> not getting anywhere at all. I only smacked the ball around for a
> couple of minutes though.
Un
On 05/21/2014 12:29 PM, Ted Felix wrote:
> Just want to wrap this FileSource stuff up and go with whatever you
> guys have decided.
No opinion.
Am I reading everything correctly, and it should be possible to build
with either Qt 4 or Qt 5 now? I attempted to build with Qt 5, and I'm
not g
On 05/17/2014 12:54 PM, Tom Breton (Tehom) wrote:
>> It would seem supplying any sort of
>> Accept-Encoding header is adequate to prevent QNetworkAccessManager
>> from doing its thing, but I have no way of verifying this in all
>> cases.
> That does seem to be it. In this QT bug report,
> https://
On Mon, May 19, 2014, at 04:33 AM, Ted Felix wrote:
>r13706 fixes the issue with ftp transfers not setting an http status
> code for isAvailable(). I've reverted isAvailable() to its original
> logic (with a comment added, so it is slightly different in appearance).
>
>This commit is
On 05/17/2014 05:05 PM, Chris Cannam wrote:
> Oh very nice, thanks. I have seen the symptom sometimes but had not yet
> tracked down the cause.
r13706 fixes the issue with ftp transfers not setting an http status
code for isAvailable(). I've reverted isAvailable() to its original
logic (with
On Sat, May 17, 2014, at 05:46 PM, Ted Felix wrote:
>This issue should directly affect Sonic Visualiser, Chris, so you'll
> probably want to bring in this change there as well.
Oh very nice, thanks. I have seen the symptom sometimes but had not yet
tracked down the cause.
Chris
--
On 05/17/2014 12:54 PM, Tom Breton (Tehom) wrote:
>> It's probably OK, but I'm always apprehensive about relying
>> on undocumented behavior to make something work.
>
> Yes, I fully understand. Given how QT worked around the opposite
> behavior, I don't think it's too likely to fail suddenly. If
> It would seem supplying any sort of
> Accept-Encoding header is adequate to prevent QNetworkAccessManager
> from doing its thing, but I have no way of verifying this in all
> cases.
That does seem to be it. In this QT bug report,
https://bugreports.qt-project.org/browse/QTBUG-18239 they addres
On 05/15/2014 03:56 AM, Chris Cannam wrote:
> If you're in a position to test
> this with ftp easily and get the status set in the appropriate place,
> that'd be great.
I'm getting closer. With the r13705 commit, I've fixed another issue
with FileSource. It would crash on http/ftp transfer e
On 05/16/2014 01:45 PM, Tom Breton (Tehom) wrote:
> The RawHeader approach seems better, actually. Too bad QT doesn't offer a
> neat solution.
>
> Or we could just live with it. Now that we know what causes it - good
> work, BTW, Tim - we can be sure the consequences aren't too serious.
Since QN
> A possible kludge might be to recompress files that have been
> automatically decompressed, in order to keep the rest of Rosegarden
> happy.
The RawHeader approach seems better, actually. Too bad QT doesn't offer a
neat solution.
Or we could just live with it. Now that we know what causes it
On 05/15/2014 04:35 AM, Chris Cannam wrote:
>
>
> On Thu, May 15, 2014, at 12:17 PM, Ted Felix wrote:
>> On 05/15/2014 06:51 AM, Tim Munro wrote:
>>> Do test QNetworkAccessManager with .rg files. I discovered an
>>> annoying tendency to automatically expand zipped files, even when
>>> they are suf
On 05/15/2014 03:49 PM, Chris Cannam wrote:
> ... though if you get an uncompressed file but it still has a .rg
> extension, that is a bit weird.
They show up in the wild sometimes, and we used to have some of them in
the device library. The ones that weren't compressed tripped up some
file ma
On Thu, May 15, 2014, at 08:43 PM, Chris Cannam wrote:
> On Thu, May 15, 2014, at 08:11 PM, Ted Felix wrote:
> > Or does rg handle uncompressed .rg files properly?
>
> I'm pretty sure it did at one point (when using the KDE library stuff),
> and it probably should...
... though if you get an unc
On Thu, May 15, 2014, at 08:11 PM, Ted Felix wrote:
> Or does rg handle uncompressed .rg files properly?
I'm pretty sure it did at one point (when using the KDE library stuff),
and it probably should...
Chris
--
"Accel
On 05/15/2014 07:35 AM, Chris Cannam wrote:
> Is it possible it's the server that notices the file is gzipped, and
> magically gives it an XML content type with gzip encoding? If the Qt
> code had at the same time become able to handle such encodings, then
> that might come out as a regression over
On Thu, May 15, 2014, at 12:17 PM, Ted Felix wrote:
> On 05/15/2014 06:51 AM, Tim Munro wrote:
> > Do test QNetworkAccessManager with .rg files. I discovered an
> > annoying tendency to automatically expand zipped files, even when
> > they are suffixed .rg.
>
>It seems to work fine for me.
On 05/15/2014 03:56 AM, Chris Cannam wrote:
> If you're in a position to test
> this with ftp easily and get the status set in the appropriate place,
> that'd be great.
I'll have a look.
Ted.
--
"Accelerate Dev Cycles
On 05/15/2014 06:51 AM, Tim Munro wrote:
> Do test QNetworkAccessManager with .rg files. I discovered an
> annoying tendency to automatically expand zipped files, even when
> they are suffixed .rg.
It seems to work fine for me. My test file is very small, though.
Was there anything interesti
On 05/14/2014 03:00 PM, Ted Felix wrote:
>
> I took a quick glance at Sonic Visualiser's FileSource, and that
> appears to be the way to go. It uses QNetworkAccessManager which
> supports http, https, and ftp transfers. I'll give it a shot next to
> make sure it will work for us.
>
> Ted.
D
On Thu, May 15, 2014, at 01:09 AM, Ted Felix wrote:
>Chris, the ftp bug is in isAvailable() and should affect Sonic
> Visualiser. Here's my fixed version (minus the debug output).
>
> bool
> FileSource::isAvailable()
> {
> waitForStatus();
>
> bool available = m_ok;
>
> //
On 05/14/2014 06:00 PM, Ted Felix wrote:
> I took a quick glance at Sonic Visualiser's FileSource, and that
> appears to be the way to go.
Indeed. I've just brought over the latest from Sonic Visualiser, and
it works perfectly. Well, almost. There is a small bug that prevents
ftp from
On 05/14/2014 12:40 PM, Ted Felix wrote:
> Next I'll have a look at Tim's patch and Sonic Visualiser...
Ok, Tim's patch works great for http, but it appears that ftp is a
bit of a pain to write a client for. Consequently, while the patched
FileSource probably works great for some ftp ser
On 05/14/2014 12:40 PM, Ted Felix wrote:
> Next I'll have a look at Tim's patch and Sonic Visualiser...
Alright. As Chris points out, "Open Location" is the standard idiom
these days, not "Open URL." My bad.
--
D. Michael McIntyre
-
On 05/14/2014 05:01 AM, D. Michael McIntyre wrote:
> It looks like you should trip openURL() dragging and dropping from a
> file manager anyway. Try that.
That was it. I tried dragging/dropping a link from a browser and
that works fine. Actually, there is a bug in the ftp support that
prev
On Tue, May 13, 2014, at 11:41 PM, Ted Felix wrote:
>What is the recommended way to open a URL in rg?
Erm, I wouldn't be surprised if the class that implements the feature
was added and then the feature itself was never actually wired up...
Probably best to do a File -> Open URL as Michael s
On 05/13/2014 06:41 PM, Ted Felix wrote:
> What is the recommended way to open a URL in rg?
With the broken file dialog, apparently. I don't see a simple way to
tweak that one at all, and propose if we want open URL functionality a
separate File -> Open URL looks like a tasty way to go.
I
On 05/13/2014 03:41 PM, Ted Felix wrote:
> On 05/11/2014 10:50 AM, Chris Cannam wrote:
>> The purpose of the class is to provide the same "file handle"
>> abstraction for files opened locally and URLs opened from remote
>> locations. It is used in for example RosegardenMainWindow::openURL().
>
>
On 05/11/2014 10:50 AM, Chris Cannam wrote:
> The purpose of the class is to provide the same "file handle"
> abstraction for files opened locally and URLs opened from remote
> locations. It is used in for example RosegardenMainWindow::openURL().
I'm having no luck coming up with a test case fo
1 - 100 of 109 matches
Mail list logo
